Consider making request-permission-to-use aware of user activation

[engedy]

The request-permission-to-use algorithm could probably take an additional bit in some shape or form prescribing whether user activation is required for showing a permission prompt if the permission state is "prompt".

Specs (e.g. Wake Lock) currently work around this limitation by essentially re-implementing its own version of this algorithm in obtain-permission, which is not great.

[engedy]

@rakuco, FYI.

[jyasskin]

I think we're missing a lot of support for user activation in the permissions spec, partly because some Firefox folks weren't convinced that it made sense to gate prompts on user activation at all. (Although #107 proposed it for all prompts, not just a subset.)

@mustaqahmed, how's whatwg/html#3851 going? I kinda think we should wait to explicitly support user activation in the Permissions spec until we have cross-browser agreement on what user activation is. I think I'd support making the "Ask the user’s permission" step give the UA a bit more choice until then, for example by saying "If the user is expected to be ready to think about a prompt, ask ...".

[mustaqahmed]

@jyasskin: We are waiting for support from other browsers to land whatwg/html#3851.

[engedy]

@jyasskin, thank you, that's great context!

I am concerned that the Permissions API spec makes no mention of user activation whatsoever, while a number of other specs either normatively require [1,2] or at least encourage using [3] user gesture/action/activation as part of their permission flows. We need to create consistency around this. Who would be the key stakeholders from Firefox to involve in this discussion?

[1] https://w3c.github.io/clipboard-apis/#privacy-permission
[2] https://w3c.github.io/deviceorientation/#deviceorientation
[3] https://immersive-web.github.io/webxr/#applicationflow

[mustaqahmed]

FYI: The HTML spec change landed yesterday.

[beaufortfrancois]

I'd love if we could make progress on this issue as this would allow specs like WebNFC to simply use the Permissions API without adding an extra step for user activation.

[mustaqahmed]

Yes, fixing this issue could simplify quite a few other specs by removing their direct link to user activation, effectively making them indirectly connected to user activation through Permissions.

[dbaron]

I'd also note that #189 is somewhat related here, in that it proposes that the API should expose more information about whether user activation is needed. (I think this issue is about the relationship of user activation to the permission requesting algorithm, and #189 is at least in significant part about the relationship of user activation to permissions.query.)

[beaufortfrancois]

@mustaqahmed @jyasskin Is there anything we can do to help move this change forward?

[reillyeon]

As an editor on the WebUSB and Web Bluetooth specifications I'm supportive of this proposal for the same reasons as @engedy's original comment. Enforcing user activation from inside a specification that depends on the Permissions API is currently very awkward.

[marcoscaceres]

I can't imagine any situation where the user would be prompted (i.e, UI is shown), but the user activation wouldn't be consumed (...but I may be lacking imagination, so someone enlighten me?).

Thus, I think we should add these checks... It would require modifying the (or adding a new) algorithm to take a promise. The transient activation would be checked (potentially causing a promise rejection), user activation would be consumed, and the prompt would be shown.

We could keep things backwards compatible by making the promise optional.

[marcoscaceres]

Sent Draft PR: #401