Open collimarco opened 1 year ago
Hi @collimarco!
Please clarify in the standard that a browser MUST display the permission prompt after an explicit user interaction (e.g. click on a button).
The spec states that:
User agents MUST acquire consent for permission through a user interface for each call to the subscribe() method, unless a previous permission grant has been persisted, or a prearranged trust relationship applies.
And, in subscribe()
's method definition:
"..invoked MUST run the following steps:..."Let permission be request permission to use "push".
So, it seems you are describing a browser bug, not a spec bug. That spec makes it pretty clear what MUST happen, but for whatever reason, Chrome mobile has chosen a different approach.
My recommendations would be to file a bug on Chrome instead?
Tangentially related: https://github.com/w3c/push-api/pull/348
I would like to report an "abusive" behavior of some versions of Chrome on mobile.
A few years ago it was said that displaying a "permission prompt" directly on page load is not a good practice.
The recommended solution - even in Google UX guides - was to explain to the user the purpose of the notifications using HTML, CSS and then if the user explicitly clicks "Subscribe" then show the actual permission prompt.
Now I have seen on a specific version of Chrome on mobile that Chrome automatically blocks the notifications even on a website that has always respected the UX requirements (e.g. double permission prompt).
This is what happens:
This is a terrible user experience and makes it really hard for a user to subscribe to the notifications, even on legit websites that follows the best practices.
Please clarify in the standard that a browser MUST display the permission prompt after an explicit user interaction (e.g. click on a button).
Note: you can reproduce the described behavior on the latest versions of Chrome on mobile on https://blog.pushpad.xyz for example.