I've seen this too. The behaviour is specific to Windows - even though we have some notification blocker implementations for the message center, we completely defer to the OS in other situations.

Finnur, Xi - is there a way to override this behaviour? Should we re-post affected notifications on screen unlock?

Do you mean ScreenLockNotificationBlocker, which is running on win, mac and linux? As Peter said, it blocks notifications and never repost them.
https://cs.chromium.org/chromium/src/chrome/browser/notifications/screen_lock_notification_blocker.cc

But out of curiosity, do we still need to block notifications on lock screen? I think they should be invisible because of the OS's native lock screen.

Re #1: As Bruce mentioned, this is happening on Windows 10 1709 where native notification is disabled. I am not sure what Finnur and I can do here.

+Jun who was looking at NotificationBlockers last year, maybe he knows who's most recently working on this feature.

Actually I haven't touched the notification code base for years, yoshiki@ would know that better, although I'm not sure the linked screen_lock_notification_blocker is the actual cause. If so I'm fine to limit it to chromeos only.

bruce, as I don't think this is a regression, we might not want to invest in changing the behavior. i can see this ending up as a notification storm on unlock, which is not necessarily an improvement. 

do we have a state of what % of our windows users aren't using native notifications?

Re #7: ~47% of Windows users are on Win10, and ~80% of them (who have OS 17134) are using native notifications. 

1 - 47%x80% = 62.4% is the rough answer to your question.

> i can see this ending up as a notification storm on unlock

You still end up with a notification storm, only now you end up with the notification storm when the next notification appears, instead of when you unlock your machine.

Having them appear on unlock - or not having them suppressed in the first place - would make the behavior much more predictable.

Here are the results of my testing on Windows version 17134:

First, to answer Peter's question about a toggle: Windows does have a toggle, but I've only seen one that controls whether notifications can show on the lock screen. I believe the default is Yes and I verified that, in that case, notifications do appear on the lock screen. Setting this value to No makes the notifications go straight to the Action Center (while the screen is locked). They are not shown when the user unlocks -- and also don't follow in the wake of other unrelated notifications (meaning: no notification storm observed). They are basically waiting in the Action Center when you unlock, with the little number in the bottom right telling you they're there.

So -- as for the original issue reported, I can not repro it on this version of Windows. Maybe MS may have been tweaking this behavior between versions? In my testing, if I manually create a notification with requireInteraction and a single button, the notification will stay on the lock screen until I interact with it. Calendar, however, does not seem to use the requireInteraction flag for their notifications, so those don't stay visible on the lock screen for very long. But that's a Calendar issue, I believe, not a Chrome issue.

Lastly, I'm not sure queuing up notifications for unlock is the right UX. Maybe instead detect that the screen is locked and display a notification on unlock saying 'x notifications were shown while the screen was locked', or something. But, even that feels a bit too 'in your face' -- I'm sure there's a segment of people that won't like that approach. I mean... some people don't even like the notification counter to be always visible. :)

To be clear, I am concerned about the behavior on Windows versions *before* 17134. The current behavior for that 62.4% of Chrome customers is:

- If I unlock my workstation at 9:59 then one minute later I will get a notification for my 10:00 meeting, and I will go.

- If I unlock my workstation at 10:01 then I will not get a notification for the meeting. There will be no indication that there is a pending notification. I will miss the meeting unless I happen to check my calendar or unless some unrelated notification comes along to "tickle" our notification center.

In this context (prior to 17134) the notifications will not show up on the lock screen so I don't think there is any reason to treat a locked workstation any different from an unlocked one.

> as for the original issue reported, I can not repro it on this version of Windows

Correct. This is a problem with Chrome's notification system, not Microsoft's, so it only applies to versions prior to 17134.

If this is so many users then it seems higher than pri-3.  Also this is definitely a regression, but not sure how long it has been regressed for.

Oh, I see. Slight misunderstanding. This is about *non*-native notifications and is fixed by later Windows versions because they switch to native notifications (Action Center does not suffer from this). 

And yes, we still have a lot of users using Chrome's notification system (but I doubt this is a regression, though).

bruce, makes sense. i think the only reasonable option is to display notifications that we have suppressed because of screen lock after the screen is unlocked.

finnur/chengx is that possible?

I don't think there is an event in WWindows that corresponds to Screen Unlocked, since the blocker uses a timer to try to detect it.  There looks like there is a bug where if the notification is added when the screen is already locked the timer is not started.  This should be a pretty easy fix inside the blocker.

I just experienced this bug on Linux, so adding the appropriate flag.

The code is tricky, so I might be wrong, but I believe that PopupsOnlyUiController should implement OnBlockingStateChanged so that it knows to re-enable popups that have been blocked by ScreenLockNotificationBlocker.

> I believe that PopupsOnlyUiController should implement OnBlockingStateChanged

Isn't the other (simpler) fix to simply not block notifications when the screen is locked, on Windows? Is there a reason to do this blocking?

If you don't care about Linux builds, you could do that, but then there is still the issue that if some blocker is ever used that "unblocks itself" then this bug will remain.

Richard, mind taking a look?

I've spent some time today to look at this, and I agree with Justin, implementing OnBlockingStateChanged seems to do the trick. I had to do this in PopupsOnlyUiController and MessagePopupCollection. Also added a browser test so we can spot this in future.

Created this CL: https://chromium-review.googlesource.com/c/chromium/src/+/1315567

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c812b6465b60bdbf5ca43f18457c9ccfcc65db36

commit c812b6465b60bdbf5ca43f18457c9ccfcc65db36
Author: Richard Knoll <knollr@chromium.org>
Date: Mon Nov 05 18:02:59 2018

fix: show pending notifications after screen unlock

This makes sure that notifications are shown to the user after a screen unlock
or after exiting fullscreen mode.

Bug: 899106
Change-Id: Iac5efa2f784e2681a41357bf7aa8f5da33830c16
Reviewed-on: https://chromium-review.googlesource.com/c/1315567
Commit-Queue: Richard Knoll <knollr@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605380}
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/chrome/browser/notifications/notification_interactive_uitest.cc
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/chrome/browser/notifications/notification_interactive_uitest_support.cc
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/chrome/browser/notifications/notification_interactive_uitest_support.h
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/chrome/browser/notifications/notification_ui_manager_browsertest.cc
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/chrome/browser/notifications/popups_only_ui_controller.cc
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/chrome/browser/notifications/popups_only_ui_controller.h
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/ui/message_center/cocoa/popup_collection.mm
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/ui/message_center/views/message_popup_collection.cc
[modify] https://crrev.com/c812b6465b60bdbf5ca43f18457c9ccfcc65db36/ui/message_center/views/message_popup_collection.h

***Mass UI Triage***

 brucedawson@ could you please help in verifying the issue?

Sorry, this isn't fixed. I mentioned that in an email discussion but failed to mention it on the bug.

I just tested with Canary (Version 73.0.3674.0 (Official Build) canary (64-bit)) on Windows 10 1709. I created an appointment and then locked my Windows workstation. I then drank coffee for several minutes until I was sure that the notification should have appeared. I unlocked my workstation and there was no notification.

I then used https://tests.peter.sh/notification-generator/ to generate a notification and it popped up, together with the (now overdue) meeting notification. I did this twice with the same results.

Is there anything I can do to debug why this isn't working as intended?

Whoops - meant to reopen this.