Require user activation for navigator.vibrate

[johannhof]

This was previously discussed in WICG/interventions#47. It looks like Chrome shipped this restriction, see https://chromestatus.com/feature/5644273861001216. I think it makes sense to make this change in the spec as well.

[anssiko]

@johannhof are you aware of other Web APIs that have spec'd this restriction (i.e. not considered an implementation detail)? If so, please drop a pointer so we make sure the prose remains consistent.

[rakuco]

User activation has had a long history in spec land AFAIR, and it is currently specified in https://html.spec.whatwg.org/multipage/interaction.html#tracking-user-activation

We are probably interested in the transient activation boolean flag, which several specs seem to check for at this point.

https://w3c.github.io/pointerlock/#dom-element-requestpointerlock says "Pointer lock is a transient activation-gated API, therefore a requestPointerLock() call MUST fail if the relevant global object of this does not have transient activation. This prevents locking upon initial navigation or re-acquiring lock without user's attention.".

The language used in algorithms in other specs (e.g. https://w3c.github.io/remote-playback/#prompt-user-for-changing-remote-playback-state or https://wicg.github.io/eyedropper-api/#dom-eyedropper-open) looks like this: "If the relevant global object of this does not have transient activation, return a new promise rejected with a "NotAllowedError" DOMException."

[anssiko]

Thanks @rakuco! That's plenty of good precedent. Also whatwg/html#5129

@johannhof does transient activation boolean flag gating for vibrate() sound good to you? We'll loop you in the PR for review if this directions seems good.

[pshaughn]

Alternatively consider sticky activation, which seems closer to what Chrome's doing. Vibration might be useful for notifying the user of something that happens a while later than the initial interaction?

[johannhof]

Sorry for the delay, I was on vacation. Thank you for chiming in to help! Chrome seems to use the sticky activation API indeed. Independent of whether that is ideal or not it's probably reasonable to update the spec to match current implementation(s). You can find some example usage in other specs here.

[anssiko]

Thanks @johannhof for confirming Chrome's implementation choice.

Per APIs gated by user activation and as suggested by folks on this issue, we have two alternatives: transient activation and sticky activation. Given the major implementation has chosen sticky activation, it is reasonable to recommend that in the spec unless good reasons surface not to.

Proposed spec change:

Inject the following step as the first one in https://w3c.github.io/vibration/#dfn-perform-vibration:

If this's relevant global object does not have sticky activation, return false and terminate these steps.

Note that there's already a step in this place that allows implementations to bail out for whatever reason which makes also existing sticky activation gated implementations compliant:

An implementation MAY return false and terminate these steps.

(I'm not a fan of such a catchall "may" but that is the escape hatch we put there long time ago after some debate IIRC.)

@johannhof looks good? I'll put up a PR if good.

FTR: Web APIs that reference either transient activation or sticky activation.

• Transient activation: Referenced in Fullscreen API, The Storage Access API, The Capture-Handle Actions Mechanism, Viewport Capture, Multi-Screen Window Placement, Capability Delegation, Close Watcher API, Compute Pressure 1, EyeDropper API, File System Access, Idle Detection API, Local Font Access API, Text Fragments, Web Serial API, WebHID API, WebUSB API, Audio Output Devices API, Clipboard API and events, Payment Request API, Picture-in-Picture, Pointer Lock 2.0, Presentation API, Remote Playback API, Screen Capture, Secure Payment Confirmation, Web Share API, WebXR Device API
• Sticky activation: Referenced in Autoplay Policy Detection, VirtualKeyboard API, Web Audio API

[anssiko]

Proposed spec patch: #30