Browser MUST always display a permission prompt after a user interaction

[collimarco]

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:

1. The user wants to subscribe to the notifications and clicks "Allow" on the first prompt (designed with HTML + CSS)
2. The user should now see the actual permission prompt to confirm the choice... but Chrome automatically blocks the notifications without asking to the user.

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.

[marcoscaceres]

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?

[marcoscaceres]

Tangentially related: #348