Enable configuration for fullscreen without transient activation

[michaelwasserman]

Accommodate user agent configurations that permit fullscreen requests without transient activation.

This is a PR for Issue #234. See the Explainer for more detail.

• [ ] At least two implementers are interested (and none opposed):
  • Chromium
  • …
• [ ] Tests are written and can be reviewed and commented upon at:
  • Test driver support for such user agent configurations is required…
• [ ] Implementation bugs are filed:
  • Chromium: https://crbug.com/1501130
  • Gecko: …
  • WebKit: …
• [ ] MDN issue is filed: …
• [ ] The top of this comment includes a clear commit message to use.

---

Preview | Diff

[michaelwasserman]

Hey @foolip, please help start review of this PR, thanks!

Chrome's initial usage is notably limited in extent, but a change like this could serve a long tail of use cases.

[michaelwasserman]

Hey @foolip, friendly ping. Thanks in advance for sharing any feedback here, or in other channels, and looping in others.

[michaelwasserman]

Hey @domenic, I see you've reviewed some recent PRs in this spec, would you mind taking a first look here? Thanks!

[domenic]

Heya, sorry I think we need to get an editor review for this one. @foolip is the right person for that.

[foolip]

@michaelwasserman sorry that I wasn't responsive to repeated pinging, taking a look now.

Can you say more about how this will be implemented in Chromium? Is it a command line flag or similar that would be enabled in kiosk mode and thus unchanging for the duration of a browsing session, or does it depend on the use of other features like the Window Management API?

The direction of my question is whether we should have UA-defined state that we look at here, or if it really is "configured to permit fullscreen without transient activation" in a global sense.

[michaelwasserman]

Thanks for taking a look! Chromium implements this with a new content setting: chrome://settings/content/automaticFullScreen

It is blocked by default, the default setting cannot be modified, but individual origins can be allowed. There is no Permissions API integration for now [1] and there is no permission prompt that sites can trigger.

Enterprise policy can allow or block any origin by pattern. Site settings WebUI (and the page info bubble) only permits users to modify this setting for isolated-app:// origins (Isolated Web Apps) for now.

The setting is somewhat similar to the longstanding chrome://settings/content/popups.

[1] Chromium will likely add Permissions API querying soon. Then, we can refine this method's steps to get the current permission state or request permission to use that new powerful feature entry as a condition for requiring transient activation.

[michaelwasserman]

To more concretely answer your questions, as they pertain to Chromium's current implementation:

Is it a command line flag or similar that would be enabled in kiosk mode and thus unchanging for the duration of a browsing session, or does it depend on the use of other features like the Window Management API?

No, Chromium's per-origin setting values can change during a browsing session, are not specific to kiosk or any other mode, and does not depend on the Window Management API.

The direction of my question is whether we should have UA-defined state that we look at here, or if it really is "configured to permit fullscreen without transient activation" in a global sense.

The UA defined state in Chromium is a per-profile, per-origin content setting.

Additionally: We could codify in spec that Chromium implements an initial usable security mitigation for this feature: Origins allowed to use Automatic Fullscreen will still require transient activation shortly after a same-origin WebContents exit

[foolip]

Thanks @michaelwasserman!

The 6 use cases from the explainer and Intent to Ship 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() 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 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 makes sense.

[foolip]

@michaelwasserman is there an open spec issue for the permission bit?

[michaelwasserman]

Thanks, @foolip!

I'll file a spec issue for permissions API support soon.

An alternative and separate explainer considered multiple operations per gesture, but that indeed fails application-driven use cases, while adding substantial complexity.

[foolip]

Per our working mode we need interest from two implementers for normative changes. This change is a little bit different from most in that default behavior isn't changing, it's closer to optional behavior or user agent-defined limitation on certain APIs. The spec already gives a lot of latitude for saying that fullscreen is not supported based on user preference etc., and this would allow for user preferences to allow fullscreen in more scenarios.

@annevk @nt1m can you comment on this for WebKit? @zcorpan can you comment for Gecko?

[annevk]

The way this is worded feels too open-ended. And https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture?tab=readme-ov-file#how-this-solution-would-solve-the-use-cases makes it seem this is in fact more narrow in scope. What gives?

[foolip]

@annevk see https://github.com/whatwg/fullscreen/pull/235#issuecomment-2116881494 for my breakdown of the use cases. The last 2 about remote desktop applications seem to rule out any more targeted approach, and the "newly connected display" use case I also put in the same bucket even though technically it could be wired up.

The 3 "one user gesture" use cases could most likely be solved in some more targeted way, and I could imagine implementer interest being different for that and the other use cases.

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture?tab=readme-ov-file#how-this-solution-would-solve-the-use-cases makes it seem this is in fact more narrow in scope

I'm not sure I understand, do you mean because the remote desktop use cases aren't explained there? The answer to "how this solution would solve the use cases?" for that would simply be "when the remote desktop goes fullscreen, send a message to go fullscreen in the local browser".

[marcoscaceres]

I honestly wonder if we even need this in the spec? If it's browser-level configurable by a user, then it could just happen transparently (in that the transient activation for this particular case is implied by the browser setting).

[michaelwasserman]

The explainer now includes Permissions API integration.

Using that Permissions API signal and HTML's definition of transient activation (which is web-exposed via The UserActivation interface), seems beneficial for spec clarity, debuggability, and feature detection. Implying transient activation in this specific case from a browser setting seems lacking in those traits.