Attaching video walk through of the issue:

Deleted: Permission-Prompt-Rate-Limiting.gif 7.2 MB

	Permission-Prompt-Rate-Limiting.gif 7.2 MB View Download

This is expected behavior please find more details here  issue#679877 

Thanks,
Could we get more details for what the expected backoff should be while asking for the notification permission to avoid the embargo? (7 days?)

More details can be found at the blink-dev announcement: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/fHl9GNxPPpA/WSS8z9GlBgAJ

We log a message to the console when a permission is automatically blocked. It links to the Chrome Status entry at https://www.chromestatus.com/features/6443143280984064.

In short, the permission will be automatically blocked if the user dismisses it (explicitly using the X or the Esc key) 3 times. It is 3 times on all versions of Chrome from 59 onwards since we find >95% of permission requests that users actually respond to have fewer than 3 prior dismissals. Hence, once you hit the 3rd dismissal from a user, we'll start throttling requests because the user is now far less likely to grant permission.

Try and request the permission at a time when you feel the user is most likely to accept it to avoid having the automatic block applied.

Thank you for timely looking into this issue, but there still seems to be a bug with the implementation:

- If the permission is "automatically blocked" (Blocked), then the browser should properly return "denied" when executing `window.Notification.permission` instead of the current "default" state which is misleading and the page could detect and handle via backing-off and not show "CTA's" to prompt users to enable Notifications. (Attaching GIF)

I also want to leave a couple of side-notes:

1. This new behavior definitely makes sense for pages auto-triggering the permission dialog on page load or without an explicit user interaction, as it prevents abuse from websites; but it feels wrong to auto-block the permission during a explicit user action such as clicking a button to trigger the permission dialog.

2. This new behavior seemed to have been introduced "quietly" and is hard to detect as it appears there has not been communicated to the developer community, opposed to the properly communicated change to use the Native Notification System (https://developers.google.com/web/updates/2017/05/nic59). Which is quite unfortunate as this change will be impacting a lot of websites including Yahoo, Facebook and AOL just to name 3.

Deleted: permission-statte-missmatch.gif 563 KB

	permission-statte-missmatch.gif 563 KB View Download

c#7: thanks for your comments.

>>> If the permission is "automatically blocked" (Blocked), then the browser should properly return "denied" when executing `window.Notification.permission` instead of the current "default" state which is misleading and the page could detect and handle via backing-off and not show "CTA's" to prompt users to enable Notifications. (Attaching GIF)

Thanks for catching this. It appears to be a bug in the notifications code that we should urgently fix. I've filed  crbug.com/730273 .

>>>> 1. This new behavior definitely makes sense for pages auto-triggering the permission dialog on page load or without an explicit user interaction, as it prevents abuse from websites; but it feels wrong to auto-block the permission during a explicit user action such as clicking a button to trigger the permission dialog.

Unfortunately, it is very, very difficult for us to distinguish between these two cases. And the largest developers, since as Facebook, simply prompt on page load. I'll reiterate that it takes 3 explicit dismisses from a user to trigger the auto block, so developers who are only ever using a UI where the user clicks a button to trigger the permissions dialog should avoid being embargoed at all (it's kind of odd if the user clicks a "send me notifications" button and then dismisses the permission prompt that comes up)

>>>> 2. This new behavior seemed to have been introduced "quietly" and is hard to detect as it appears there has not been communicated to the developer community, opposed to the properly communicated change to use the Native Notification System (https://developers.google.com/web/updates/2017/05/nic59). Which is quite unfortunate as this change will be impacting a lot of websites including Yahoo, Facebook and AOL just to name 3.

Thanks for this feedback. We're sorry if it seems like this was undercommunicated. We announced it (like all changes) in the Chrome 59 beta blog post that came out six weeks prior to stable release (https://blog.chromium.org/2017/05/chrome-59-beta-headless-chromium-native.html). It was also announced on the blink-dev developer group and on the Chrome Status portal. Additionally, our developer guidance for notifications uses explicit buttons to get notifications permission (e.g. https://developers.google.com/web/fundamentals/getting-started/codelabs/push-notifications/). This UX really shouldn't be affected by this change since a user would have to click the button to get notifications, then decide to explicitly dismiss the permission prompt.