Re: [whatwg/fullscreen] Enable configuration for fullscreen without transient activation (PR #235)

Thanks @michaelwasserman!

The 6 use cases from the [explainer](https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture/blob/main/README.md#use-cases) and [Intent to Ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/WOch5LPq9RY) fall into a few categories:

> Show fullscreen remote desktop content on multiple displays with one user gesture
> Swap fullscreen windows between displays with one user gesture

I believe these are cases when you'd like two `requestFullscreen()` calls in a single event handler, but the first one consumes user activation, and thus the second one fails.

> Open a popup and make it fullscreen with one user gesture

This is similar, but a [`window.open()`](https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-open) call followed by `requestFullscreen()`. I can't find where in the spec transient user activation is consumed, but I can see with [a test case](https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12737) that Chrome, Firefox and Safari all agree on the behavior, that the `requestFullscreen()` call should be rejected.

For these cases one could look into ways of making `requestFullscreen()` + `requestFullscreen()` or `window.open()` + `requestFullscreen()` work. With all the different things that consume user activation that one might possibly want to do together, I suspect it would have to be a solution on the shape "do these things that consume user activation, then actually consume". @mustaqahmed is this something that's ever been discussion?
 
> Automatically extend a fullscreen desktop session onto a newly connected display

This is a little bit similar to the "triggered by a user generated orientation change" condition already in the spec, but I don't think it would be reasonable to give a "display connected" event the same powers by default, since there's no user expectation that connecting a display also allows a website to go fullscreen. So it effectively falls into the next category:

> Request fullscreen after transient activation expiry, e.g. slow remote host response
> Apply remote app fullscreen state locally, e.g. on app launch or system events

These are both cases that the browser has no visibility into, it's stuff happening at the application layer.

So in summary, because of the last three use cases in particular, I think the "user agent has been configured to" approach similar to [popups](https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable) makes sense.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/235#issuecomment-2116881494
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fullscreen/pull/235/c2116881494@github.com>