Allow fullscreen on already fullscreen elements without user activation

[quisquous]

@mustaqahmed requested that I file an issue for this.

In this text, I'm proposing that we add some text that requesting fullscreen on an already fullscreened element does not require nor consume user activation. This is currently how Chrome behaves, and so clarifying this text would be useful.

Additionally, as a part of window placement, we would like to extend requestFullscreen to have an additional screen parameter to open up fullscreen on a different display. Rerequesting fullscreen with a different screen will move the window to another screen (preserving fullscreen). Having this text would allow us to not require user activation for this behavior, solving this bug.

[mustaqahmed]

I just confirmed that Firefox work exactly like Chrome: if an element is already fullscreen, calling element.requestFullscreen() again without user activation is a no-op from user's perspective (nothing changes) but the Promise is rejected and a console error is emitted. It seems to me that silently accepting the Promise in this particular case would be a no-change for users, and a very subtle change for developers. In particular, the lack of a fullscreenchange event would still indicate to developers that nothing has changed.

[mustaqahmed]

I now feel like I misinterpreted the original request here: this is asking to drop the user activation requirement if Document.fullscreenElement is not null.

FYI for @bradtriebwasser @michaelwasserman.

[michaelwasserman]

Indeed, see supportive statements in this related comment thread on the PR adding user activation consumption to requestFullscreen.

IMO, it seems totally reasonable to grant fullscreen element changes without user activation.
Whether or not we'd allow fullscreen display changes without user activation is less straightforward.
The original Chromium bug was fixed by adding support for fullscreen capability delegation

[foolip]

One case I'm not sure about is nested fullscreen with iframes. If myblog.com embeds videohosting.com in an iframe and the user fullscreens a video in the iframe, myblog.com could later overlay or replace the video, although it couldn't mute and unmute the audio. If myblog.com is hostile there are already plenty of bad things it can do, but a seamless transition between the real videohosting.com and something else might be new.

I'm not sure if this is important or not, but it would be good to look into.

[mustaqahmed]

Yes, good catch that we need to avoid seamless fullscreen transition between two different origins.

Perhaps we can say: elem.requestFullscreen() will require either:

• transient user activation (as we currently have in Step 5 here), or
• Document.fullscreenElement.ownerDocument === elem.ownerDocument.

@foolip What do you think?

Any chance an easier answer lies in the "relevant global object" in Step 5 above? The call elem.requestFullscreen() cannot be made from a cross-origin Window because that Window can't access elem---at least in Chrome. I don't know if this site isolation behavior is fully spec-ed. @domenic?

[annevk]

@mustaqahmed well with document.domain it can be, right? (The security model is specified in HTML and while it predates site isolation, it comes down to the same thing, roughly.)

[foolip]

In order to avoid issues with iframes, I think the simplest fix would be to require that there's no iframe on the fullscreen element stack.

[annevk]

Could someone perhaps clarify the objectives from OP? And perhaps open a separate issue for the second paragraph as that seems rather separate?

[foolip]

@quisquous can you elaborate on the motivation?

[michaelwasserman]

It's okay to close this issue for now, and folks can reopen it if the need arises.

The original motivation was moving a fullscreen element to another display of the device (by calling requestFullscreen with a new target screen in the FullscreenOptions dictionary, as supported by Chrome), when triggered by a click on a separate window. That was made possible via Capability Delegation of Fullscreen requests.

Just FYI, @quisquous is no longer actively working in this space.