Thanks for the report.

The page info dialog is accessed by clicking the lock icon next to the URL in the Chrome omnibox. Otherwise, you can clear your browsing data which will also clear the temporary block. 

More generally, we're not likely to provide a setting to override this, since we'd consider such a setting to be extremely infrequently used across all of Chrome's user base.

Thanks for the quick reply.

I am aware of the lock icon, but how do I clear the temporary block from there?

The permission which is blocked should have the string, "Automatically blocked" displayed underneath it, as well as the "Blocked" state next to it. Reset the value from "Blocked" to "Ask" to clear the temporary block.

If you do not see a permission with "Automatically blocked", that means you are requesting a permission from a cross-origin iframe, which is deprecated and will stop working from Chrome M61.

The permission which is blocked (Notifications) still has the value 'Ask'. Please find screenshot attached.
I get the following message in the console: "PushMessaging permission has been blocked as the user has dismissed the permission prompt several times. See https://www.chromestatus.com/features/6443143280984064 for more information."

I am not requesting permission from an iframe.

Deleted: Screen Shot 2017-06-26 at 1.00.07 PM.png 56.9 KB

	Screen Shot 2017-06-26 at 1.00.07 PM.png 56.9 KB View Download

How are you requesting the permission? Are you using the PushManager directly, or the Notifications API?

I am using the PushManager directly

Looks like the embargo for the push messaging permission isn't properly propagated up to page info. Reopening this bug.

As a work around, please use the Notifications API to request notifications permission (functionally, it is the same). That is, use Notification.requestPermission first, and then call PushManager.subscribe().

The problem with the proposed workaround is that it's common to invite the user to subscribe for messages (for example, using a popup, or a button on the page), and to call requestPermission only if the user responds to the invitation. This is good practice since it avoids requesting permission unless we have some indication that the user has asked for it. However, since the embargo change, we now risk inviting the user to subscribe when it's not possible to do so. When under embargo, Notification.permission still returns "default" but all called to Notification.requestPermission return "denied:. This results in a bad user experience.

c#9: As I commented elsewhere, Notification.permission will correctly return "denied" as of Chrome 60. We're expecting to have this bug fixed too in 61, and possibly be able to bring it forward to 60 as well.

Thanks again for taking the time to file this bug so that we can get the fix in asap.

c#10: Good news :)
We came up with an alternative workaround:
1. On Chrome 59, if Notification.requestPermission() resolves to 'denied', immediately check Notification.permission. If it's 'default', set a flag in localStorage to record that the client is embargoed.
2. Wrap Notification.permission checks in a function that will return 'denied' if the embargoed flag is set.
2. On script init, if the Chrome version is 60 and the 'embargoed' flag is set, clear the flag so that we trust the value of Notification.permission again

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

commit acc56f7ade646212b19d55ea4fc9a4d7e5bc935d
Author: Patricia Lor <patricialor@chromium.org>
Date: Tue Jul 04 01:21:56 2017

Permissions: Always embargo the content setting's storage type.

Always use the content setting storage type in PermissionDecisionAutoBlocker.
This will consolidate embargo for notifications and push messaging, so that too
many dismissals/ignores of the permission request for either of these
ContentSettingTypes will only embargo notifications.

This fixes a bug where push notifications could be embargoed, but could not be
overridden by the user because it is not exposed in the Page Info bubble UI.

Bug:  736702 
Change-Id: Ib5dc7a0c735bef8316e1bab7e4010acef459c0ed
Reviewed-on: https://chromium-review.googlesource.com/557620
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Commit-Queue: Patricia Lor <patricialor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#484038}
[modify] https://crrev.com/acc56f7ade646212b19d55ea4fc9a4d7e5bc935d/chrome/browser/permissions/permission_context_base.cc
[modify] https://crrev.com/acc56f7ade646212b19d55ea4fc9a4d7e5bc935d/chrome/browser/permissions/permission_context_base.h
[modify] https://crrev.com/acc56f7ade646212b19d55ea4fc9a4d7e5bc935d/chrome/browser/permissions/permission_context_base_unittest.cc
[modify] https://crrev.com/acc56f7ade646212b19d55ea4fc9a4d7e5bc935d/chrome/browser/permissions/permission_decision_auto_blocker.cc
[modify] https://crrev.com/acc56f7ade646212b19d55ea4fc9a4d7e5bc935d/chrome/browser/permissions/permission_util.cc
[modify] https://crrev.com/acc56f7ade646212b19d55ea4fc9a4d7e5bc935d/chrome/browser/permissions/permission_util.h

This should be fixed now, but I'll wait for Canary tomorrow to verify the change works then request a merge to m60.

The NextAction date has arrived: 2017-07-05

Verified working on Canary 61.0.3149.0.

Repro steps used:
1. Navigate to https://serviceworke.rs/push-subscription-management_demo.html (thanks dominickn@ for finding the demo link)
2. Click the "Subscribe" button and press escape when the prompt asking for notifications appears.
3. Repeat Step 2 until the prompt no longer shows up.
4. Open the Page Info bubble (click info icon next to URL) and verify the "Notifications" permission reads "Automatically blocked" underneath it.

Requesting merge to m60 and also updating the status since I forgot to do that earlier.

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

Thanks for the fix - however, my recommendation is to wait until M61 if this is not urgent. We are stricter with merges to M60, since it's way past branch point and stable is only a few weeks away. Please confirm if this can wait until M61. 

Just noticed this is broken in m59, confirmed working in canary. Thanks!

p.s. due to the confusion this creates when build custom UI around enabling enabled notifications, users would benefit from this being merged sooner rather than later

Another vote for fixing as early as possible - working around this is proving difficult, and may mean a bad UI experience for users of Chrome 59.

Thanks all! @Dom, Patti, do you have a hand-wavey sense of how many users this will affect (i.e. will wind up in this bad state without seeing the pageinfo UI), so we can make a call on whether to wait till 61 (based on recommendation in c#17)?

There are approximately 24 million push messaging permission prompts shown per day on stable and over a third of them are dismissed. Based on the dev feedback here, I would strongly advocate for merging the fix to M60. We also took care to make the CL as small as possible to make the merge safer.

Great, thanks all for feedback. Approving merge to M60. 

Please merge this to M60 ASAP. branch:3112

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

commit ab33058ec585f6ef04fe46522502c452fec2c6fd
Author: Patricia Lor <patricialor@chromium.org>
Date: Tue Jul 11 00:00:32 2017

Permissions: Always embargo the content setting's storage type.

Always use the content setting storage type in PermissionDecisionAutoBlocker.
This will consolidate embargo for notifications and push messaging, so that too
many dismissals/ignores of the permission request for either of these
ContentSettingTypes will only embargo notifications.

This fixes a bug where push notifications could be embargoed, but could not be
overridden by the user because it is not exposed in the Page Info bubble UI.

TBR=patricialor@chromium.org

(cherry picked from commit acc56f7ade646212b19d55ea4fc9a4d7e5bc935d)

Bug:  736702 
Change-Id: Ib5dc7a0c735bef8316e1bab7e4010acef459c0ed
Reviewed-on: https://chromium-review.googlesource.com/557620
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Commit-Queue: Patricia Lor <patricialor@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#484038}
Reviewed-on: https://chromium-review.googlesource.com/565663
Reviewed-by: Patricia Lor <patricialor@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#571}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/ab33058ec585f6ef04fe46522502c452fec2c6fd/chrome/browser/permissions/permission_context_base.cc
[modify] https://crrev.com/ab33058ec585f6ef04fe46522502c452fec2c6fd/chrome/browser/permissions/permission_context_base.h
[modify] https://crrev.com/ab33058ec585f6ef04fe46522502c452fec2c6fd/chrome/browser/permissions/permission_context_base_unittest.cc
[modify] https://crrev.com/ab33058ec585f6ef04fe46522502c452fec2c6fd/chrome/browser/permissions/permission_decision_auto_blocker.cc
[modify] https://crrev.com/ab33058ec585f6ef04fe46522502c452fec2c6fd/chrome/browser/permissions/permission_util.cc
[modify] https://crrev.com/ab33058ec585f6ef04fe46522502c452fec2c6fd/chrome/browser/permissions/permission_util.h

Done, thanks everyone!