There is currently a bug (perhaps a limitation) where manually going from "Block" to "Allow" will not correctly reflect the updated push permission on the main page. This leads to issues such as custom prompting widgets not dismissing or simply continuing to appear altogether despite the permission already set to "Allow"
To fix it in its current state:
Chrome.
Firefox doesn't work at all do to the new user-gesture requirement causing the programmatic native permission request from failing and flickering the popup before it gets dismissed. (This is another issue altogether)
I suspect this has always been broken.
@dvoytenko any insights here?
I checked it on Chrome MAcOS and issue's reproducible.
/to @kristoferbaxter for triage.
Hello there! is there any advance on this topic?
Hello, just checking if there is any progress?
@kevinkimball could you take a look at this please?
I can confirm that this is the behavior. Checking in the comments for the code, it appears that the permission state is stored in state to avoid having to open a popup to the canonical URL every time when the page is being served from the cache. Here is the relevant comment. Open to suggestions but appears this is the intended behavior, and document authors can customize or omit the blocked state for the push widget.
@kevinkimball ,
Thanks for the response. @jkasten2 is there anything you can add?