fullscreen
fullscreen copied to clipboard
whatwg
Consume user activation in `element.requestFullscreen()`
Depends on https://github.com/whatwg/html/pull/3851.
Fixes https://github.com/whatwg/fullscreen/issues/152.
https://github.com/web-platform-tests/wpt/pull/16758 has been merged into wpt repository. Three new tests about this behavior are now in https://w3c-test.org/fullscreen/api/ element-request-fullscreen-twice-manual.tentative.html element-request-fullscreen-two-elements-manual.tentative.html element-request-fullscreen-two-iframes-manual.tentative.html
@foolip, can we help move this along? I'm happy to rebase it and also take care of any changes after #208.
This would probably solve the issue @marcoscaceres raises in https://github.com/web-platform-tests/wpt/issues/36727 of giving a cross-browser way of consuming user activation.
I guess it depends on what features/API calls follow a call to .requestFullScreen()... I see there is mention of Pointerlock in the bug and Screen Orientation Lock is another.
I'm simultaneously hoping we can prevent the Screen Orientation API (which depends on FS API) from arbitrarily changing the screen orientation without a user gesture.
If you have an Android device handy, try this out in Chrome: https://marcoscaceres.github.io/playground/annoying.html
(if you can't try it out, it loops rapidly changing the screen orientation making it difficult of users to access the browsers UI - you need to either turn off the screen or quickly swipe from the bottom to stop it).
I personally don't think the above behavior should be acceptable for any API to do on the Web. So, I was hoping we wouldn't consume the user activation in FS API, but rather have the Screen Orientation API consume the user activation.
Alternatively, we could have it consume the user activation if #186 was in place, all in one go. The advantage being that it wouldn't breaking any sites that are depending on FS API to not consuming the user activation.
For pointerlock, maybe a solution like #186 could also work. You request them all at once, and exiting fulls screen releases all the locks.
Currently, Gecko also consume the user activation as we had received a bug of trapping the user in fullscreen mode, which invites DOS and spoofing possibilities. And for pointer lock, we allow it without a vaild user activation if document is in fullscreen mode.
Discussing with my WebKit colleagues... but if both Gecko and Chromium consume it, we may follow suit. Let me get back to you.
And for pointer lock, we allow it without a vaild user activation if document is in fullscreen mode.
That is contrary to what is in the Pointer Lock spec, right? Why don't we just link the actions together via a mechanism like in #186?
(also, we should really rewrite the pointer lock spec to integrate properly with the Full Screen API)
Currently, Gecko also consume the user activation as we had received a bug of trapping the user in fullscreen mode, which invites DOS and spoofing possibilities.
Chrome originally proposed this consumption behavior to prevent a spoof, see https://crbug.com/852645.
And for pointer lock, we allow it without a vaild user activation if document is in fullscreen mode.
That is contrary to what is in the Pointer Lock spec, right? Why don't we just link the actions together via a mechanism like in https://github.com/whatwg/fullscreen/issues/186?
IIRC Chrome added a similar hack to support some compat argument, can't recall any details! Yes, #186 would be nice.
(Edited to fix the bug link)
@EdgarChen, if we go with something like #207 (new dictionary member), would you be willing to remove the pointerLock workaround in Firefox? That way, we can just have a consistent model across three specs.
Similar question for Chrome folks. I'm willing to spec that up if everyone is supportive.
@EdgarChen, if we go with something like #207 (new dictionary member), would you be willing to remove the pointerLock workaround in Firefox?
To clarify this a bit more: This is not a workaround added for consuming user activation, we behave the same all the way back to Firefox 22 at least (before the current user activation model in spec is proposed). I am worried that removing this would cause compatibility problem. :(
@foolip, could you kindly please update the PR to use the "new" PR template? (I don't have the ability to edit the top comment)
Also, will you be updating any affected tests?
@marcoscaceres there are 3 tests in wpt that are tentative due to #152:
https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/element-request-fullscreen-twice-manual.tentative.html https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/element-request-fullscreen-two-elements-manual.tentative.html https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/element-request-fullscreen-two-iframes-manual.tentative.html
But I think with consuming, this can be reduced to just the first test, ensuring the second call is rejected.
Filed WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=247920
Thanks for the details about the tests, @foolip. If those can get updated and changed to non-tentative, that would be great.
I have a feeling that there is nothing wrong to allow requestFullscreen without user activation when the document is already in fullscreen, or is entering fullscreen (by a previous call). Though to be honest I'm not sure whether it is useful to allow that either.
@upsuper I think you're right about that, since the page script already has full control over what's being presented and could replace all the contents of the current fullscreen element. However, that'd be a change from the currently implemented behavior, and I'd prefer to handle that separately from this. Can you file an issue if you think we should change that?
This is now also implemented in WebKit.
@foolip, anything left to get this merged?
@marcoscaceres sorry I totally dropped the ball here. I've updated the PR and all I need now is review from someone with write access. Paging @annevk, as @domenic seems to be OOO today.
Thanks @annevk! Let me try inverting the preceding steps and see if you like that.