Would you mind providing us with a sample testcase for repro?

I'm not quite sure what format I'd supply that in, since reproducing this issue requires changing System Preferences.

As far as registering for push goes, if you visit https://gauntface.github.io/simple-push-demo/, put a breakpoint on the "then" block of "serviceWorkerRegistration.pushManager.subscribe" (you can use dev inspector's search pane to find that code in push-client.js), and toggle "Enable Push Notifications" on, you'll see the browser returning the push subscription, regardless of whether Notifications are actually enabled at the OS level or not.  You'd need your own web push server to verify seeing GCM returning a 410 when Notifications are disabled, but that's all expected.

Thank you for providing more feedback. Adding requester "ligimole@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on reported version 62.0.3198.0 , on latest canary 63.0.3208.0 using Mac 10.12.6 and is reproducible with below steps.

1.Changed notification settings for Google Chrome at the OS level (System Preferences -> Notifications -> Google Chrome -> None
2.Launched chrome and navigated to https://gauntface.github.io/simple-push-demo/ >> Used inspect >> Navigated to push-client.js
3.Searched for serviceWorkerRegistration.pushManager.subscribe and put breakpoint >> Now enabled Push Notifications and saw Notification bubble

Same behaviour is seen from M50 series i.e; 50.0.2624.0. Hence marking it as Untriaged and adding appropriate labels for further inputs from respective team

This isn't actually a regression -- the mechanisms through which all of Chrome's notifications could be disabled are still available (i.e. the permission), it's just that there's one more switch that matters now.

This situation is very similar to what we're having on Android, so +awdf, owencm and hanxi for their thoughts.

In short: what should happen to notification permissions (and associated push subscriptions) if the OS-level permission has been revoked? If the user disables notifications in the Mac OS X system UI, even if temporary, do they expect (all) push subscriptions to drop?

I see, yes. I agree that if we fix this there's a use-case where a user temporarily disables notifications at the OS level, a site tries to register them, sees "denied" and removes the subscription from its backend, the user re-enables notifications at the OS level, and now they're unsubscribed when they might have still been expected to be subscribed.

The alternative I'm facing today though is that there are large portions of the userbase with notifications disabled at the OS level who are continuously reregistered and removed from our site's backend - each time the push bounces we remove their subscription, but each time they visit the site their browser gives it back to us again. Since Chrome's notifications became disableable at the OS level, we're seeing sustained bounce rates of ~30% across a userbase of ~500k users.

I don't have strong opinions. 

On the one hand it seems sensible to unsubscribe the user, on the other hand I can see it would be annoying to lose all subscriptions just from toggling it off and on again.

Perhaps we can do a time based thing, so they're only unsubscribed if it's been disabled for some time.. not super keen on adding that complexity though, especially since (at least on Android) we can't listen for the toggle event, we have to poll it.

Ian, you say that the push bounces - how do you measure this? What I'm saying is that we *don't* do anything right now, Chrome acts exactly the same whether notifications are enabled at the system level or not. It's not observable.

If you mean push messages that are being rejected by FCM, then something happened to explicitly unsubscribe those users. There are a variety of reasons why that may happen, and we definitely can help you look in to it, but that's orthogonal to the OS-level switch.

#c9 - agreed that time-based detection may be an option

When I say bounce, I mean that when you attempt send push to an endpoint in this state, FCM responds with a 410 - https://developers.google.com/web/fundamentals/engage-and-retain/push-notifications/common-issues-and-reporting-bugs#http_status_codes - I can reproduce this happening to an endpoint that successfully received push (returned a 201, displays the push to the user) directly before turning off the OS-level switch.

This behavior appears to have changed somewhat recently - now, in this scenario, Chrome will deliver a push directly to the notifications tray (but not display it on the user's screen) instead of rejecting it.

**Mass UI Triage**

This issue is still reproduced on Mac OS 10.13.3 from M60 to latest canary-72.0.3617.0.Could some one from dev please take a look.

Thanks..!!