Only allow permissions.request() during user interaction

[mnoorenberghe]

Some quotes from Google:

We believe users should only see a permission prompt if they’ve demonstrated willingness to grant that permission, or at minimum, intent to use a feature which requires that permission. In particular, we strongly advise against triggering permissions prompts on page load.

Showing users permission prompts they aren’t interested in is distracting and spammy. To ensure Chrome users get the best experience on the web we’re exploring automatically denying permission prompts from sites that display prompts which users largely ignore or deny (or worse, revoke).

from https://docs.google.com/document/d/1WNPIS_2F0eyDm5SS2E6LZ_75tk6XtBSnR1xNjWJ_DPE/edit#heading=h.55stxhevs7pi

Always request access to location on a user gesture

from https://developers.google.com/web/fundamentals/native-hardware/user-location/user-consent

This new API seems like the perfect opportunity to enforce this restriction to avoid spammy popups: Permission requests shouldn't appear if permissions.request() isn't called as a result of user interaction. The older permission APIs can eventually be deprecated in favour of .request().

[mounirlamouri]

Note that the location request requiring a user gesture isn't actually true.

However, I agree that we should probably be requesting a user gesture. This has been in my TODO list for a while but my concern is that websites might use other means to request a permission than the Permissions API if we add restrictions compared to existing APIs (for example, Notifications.requestPermission() or navigator.geolocation.getCurrentPosition(function(){})). This said, it might be a good thing to do to enforce good practices and if new APIs use the Permissions API for request, they will force websites to use this pattern.

@adrifelt @annevk WDYT?

[adrifelt]

How we define "user interaction" has always been a sticking point in the past. I would be in favor of this as long as we get a solid definition of "user interaction."

[mnoorenberghe]

I think allowed to show a popup is the most common definition.

[jyasskin]

And it's what I've used for Web Bluetooth. We've had some complaints, but most have been because Chrome doesn't propagate user gestures through Promise.then, which is just a bug.

[adrifelt]

I was under the impression that various odd things are treated as user gestures, like hitting "Esc."
cc @kjayc

[jyasskin]

If the things browsers treat as user gestures don't match https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup, we should get HTML updated. It's also possible we should split "allowed to show a popup" into different terms that cover popup windows vs these permissiony popups. We should probably do both of those separately from deciding whether permissions.request() should insist on a user gesture.

[mounirlamouri]

@adrifelt what would you call a user interaction? FWIW, I don't think we should stick with "show a popup" it's an old concept that was meant for anti-spam. Different features might have different rationale.

[annevk]

It was meant to make sure the user requested it and not the page. It maybe should be renamed though. It is however what various specifications have been adopting and what I think is the fundamental concept in implementations. E.g., the fullscreen API uses it too.

One problem with "allowed to shop a popup" is touch events, but it's unclear how to solve it for those as I understand it.

[raymeskhoury]

It seems like the definition doesn't count plain keyboard events, only clicks and form change events. Is that right? I guess that would avoid counting 'esc' which seems good (and possibly part of the motivation). Still, it seems like we do allow esc to trigger a popup in Chrome: http://jsfiddle.net/Ltyqd05m/5/ Not in FF though :)

To me it seems like the requirements for popups vs permissions are going to be similar, but if there were good reasons to have a different definition that seems ok too.

[mounirlamouri]

@annevk for example, we want Fullscreen to be triggered by other things like orientation change. We are still exploring this but if it happens, it would no longer fully follow the "pop up" rules. Also, it seems that there are two types of user gesture requirements: security and spam. For some, we might be more relaxed than others. Furthermore, Blink is looking into changing user interaction to no longer accept touch events apart from clicks.

In short, I don't think we should ignore the "allowed to show a popup" rules but we should allow ourselves to think freely outside of this box.

[annevk]

No disagreement there. I just disagreed with the characterization that it's old. It's still very much alive and important.

[TanviHacks]

Regardless of how we exactly define user gesture, does anyone disagree that Permission Prompts should require user gesture? Are there any permissions for which this requirement doesn't make sense (ex: push notifications)?

[martinthomson]

@TanviHacks, I think that push depends a great deal on how you intend to trigger the prompt. Most uses that I've seen have a button that says "Enable Notifications". That works.

[jyasskin]

I'm seeing consensus that we should require a user gesture in permissions.request(). Whether we should have request() at all is more contentious, but if it exists, it should require the gesture. I'm going to wait to add the requirement until we've got the overall model figured out, but then I'll send a PR.