Consume user gestures in requestFullscreen

[foolip]

There is a Chromium (non-public) spoofing bug involving requestFullscreen that makes it seem like a good idea to consume user gestures in requestFullscreen as a mitigation. There may be web compat issues with such a change so it will be tested before a spec change is proposed in earnest.

This is a tracking bug for the tentative tests that may go with this change, so that they don't remain tentative forever.

@Summerlw @mustaqahmed

[upsuper]

What do you mean by consume user gesture?

[annevk]

cc @EdgarChen

[mustaqahmed]

Consuming user activation (or user gesture) means after requestFullscreen() is successful, the user activation is "gone" so another requestFullscreen() call will fail unless there is another user activation in-between. Essentially we are proposing one call per user interaction. Currently any number of calls can be made until the user activation expires, which seems counter-intuitive (and it is one reason the UI spoofing bug was possible).

A bit of a background: here are three different ways APIs typically depend on user activation.

[upsuper]

Sounds like a reasonable idea.

Another question would be whether other operations which require user activation / user gesture consumes that as well? i.e. if I trigger something else in user activation, and then requestFullscreen() should that still work?

[LanWei22]

Other operation like pop up windows consume user activation. For the same user activation, if the pop up window opens first and it consume the user activation, the requestFullScreen() will not work. This is defined in the current user activation v2 spec.

…

On Sat, May 18, 2019 at 8:50 PM Xidorn Quan ***@***.***> wrote: Sounds like a reasonable idea. Another question would be whether other operations which require user activation / user gesture consumes that as well? i.e. if I trigger something else in user activation, and then requestFullscreen() should that still work? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#152?email_source=notifications&email_token=ACN2LK3KIYN6R5D3Z4WFKBLPWCP5HA5CNFSM4HMSX7EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVWYSIA#issuecomment-493717792>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACN2LK4Y6FU33QVR7MDPIOTPWCP5HANCNFSM4HMSX7EA> .

[foolip]

FWIW, the main compat risk I see with this is that people might call video.requestFullscreen() + video.play() in the same event handler, and that consuming the gesture will mean the video won't play. Combination with other APIs that consume user activation are also possible of course, but we'll have to see which come up in practice.

@mustaqahmed @Summerlw do you anticipate this type of problem, and is there a fix we can make if it break sites?

[mustaqahmed]

Yes, we expect problems like this. One possible way to fix this is to reverse the order of the two calls, so replacing:
video.requestFullscreen() then video.play()
with
video.play() then video.requestFullscreen()
would fix this specific problem. We expect this to work in most cases because only a handful of APIs consume user activation today (e.g., in Chrome only popups and some "types" of navigation consume). If the second API used with fullscreen is either popup or navigation, it could be hard to fix easily.

[foolip]

Right, as long as no two APIs that consume user activation make sense together, then it can be avoided.

[foolip]

@mustaqahmed is there an existing spec concept that can be referenced to produce a PR for what this change would be spec-side?

[mustaqahmed]

The consumption concept is still not covered by any spec. We have this PR for User Activation v2 which would make the concept formal.

[foolip]

I see, so the concept would be "consume user activation" which takes a window. Then the spec change would be to just do that somewhere in https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen, would it be after step 6 if error is false?

[mustaqahmed]

Correct. I think we would add a step "consume the user activation" somewhere in between Steps 11~14. We have to make sure a rejected promise (Step 10) doesn't consume.