Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable configuration for fullscreen without transient activation #235

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

michaelwasserman
Copy link

@michaelwasserman michaelwasserman commented Jan 25, 2024

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

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


Preview | Diff

Rough PR to support fullscreen without transient activation.
@michaelwasserman
Copy link
Author

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 michaelwasserman changed the title WIP: Enable configuration for fullscreen without transient activation Enable configuration for fullscreen without transient activation May 9, 2024
@michaelwasserman
Copy link
Author

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

@michaelwasserman
Copy link
Author

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

@domenic
Copy link
Member

domenic commented May 16, 2024

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

@chrishtr chrishtr requested a review from foolip May 16, 2024 15:32
@foolip
Copy link
Member

foolip commented May 16, 2024

@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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

foolip commented May 17, 2024

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.

Copy link
Member

@foolip foolip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editorially I think this looks good. If a permission is added, I suspect that the phrasing will become a bit unwieldy and we'll want to break this out into a helper similar to "fullscreen is supported", but that's not necessary just yet.

@foolip
Copy link
Member

foolip commented May 17, 2024

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

@michaelwasserman
Copy link
Author

michaelwasserman commented May 17, 2024

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
Copy link
Member

foolip commented May 17, 2024

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
Copy link
Member

annevk commented May 17, 2024

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
Copy link
Member

foolip commented May 17, 2024

@annevk see #235 (comment) 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
Copy link
Member

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants