Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Contact emails

m...@chromium.org, fugu...@chromium.org

Explainer

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Specification

https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

Design docs

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Summary

A new "Automatic Fullscreen" content setting permits Element.requestFullscreen() without a user gesture, and permits browser dialogs to appear without exiting fullscreen.

The setting is blocked by default and sites cannot prompt for permission. New UI controls are limited to Chrome's settings pages [1] and the site info bubble. Users can allow Isolated Web Apps [2], and enterprise admins can allow additional origins with the AutomaticFullscreenAllowedForUrls policy.

Combined with Window Management permission [3] and unblocked popups [4], this unlocks valuable fullscreen capabilities:

- Open a fullscreen popup on another display, from one gesture

- Show fullscreen content on multiple displays from one gesture

- Show fullscreen content on a new display, when it's connected

- Swap fullscreen windows between displays with one gesture

- Show fullscreen content after user gesture expiry or consumption

[1] chrome://settings/content/automaticFullScreen and site details pages

[2] User control is initially scoped to security-sensitive apps; see https://chromestatus.com/feature/5146307550248960

[3] For multi-screen window placement features; see https://chromestatus.com/feature/5252960583942144

[4] To similarly permit window.open() without a user gesture; see chrome://settings/content/popups

Blink component

Blink>Fullscreen

Search tags

Fullscreen, requestFullscreen, transient activation, user gesture, content setting

TAG review

N/A. This is not proposing a new or changed web API, but a browser-specific permission configuration.

Risks

Interoperability and Compatibility

Element.requestFullscreen() may now succeed instead of rejecting without transient activation. The design doc considers some nuanced windowing corner cases. This feature is initially only available to security-sensitive apps and enterprise allow-listed origins.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1020)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/345)

Web developers: Positive. Requested by 1st and 3rd party partners, particularly around VDI: https://github.com/w3c/window-management/issues/7 https://github.com/w3c/window-management/issues/98 https://github.com/w3c/window-management/issues/92 https://crbug.com/315859364

Ergonomics

The explainer discusses prospective feature detection support.

Activation

Users or admins must grant the new Automatic Fullscreen content setting, plus the Popups & Redirects content setting and the Window Management permission, and to take full advantage of fullscreen windowing features.

Security

This capability exacerbates preexisting fullscreen usable security concerns, so sites cannot show a permission prompt, and user controls are initially scoped to IWA contexts.

WebView application risks

None; this feature is not supported on WebView for now

Debuggability

Sites can debug via Element.requestFullscreen()'s promise, which may reject with a TypeError containing a message, the document `fullscreenElement` property, document `fullscreenchange` + `fullscreenerror` events, and devtools console messages. Transient activation state is exposed via navigator.userActivation.isActive. Script can check the window.location.href's scheme for `isolated-app:` to assess initial availability of user control for the current context.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No; Initial support targets desktop platforms.

Is this feature fully tested by web-platform-tests?

No; WPT coverage is not yet available, and necessitates test driver controls for this new content setting.

DevTrial instructions

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture/blob/main/HOWTO.md

Flag name on chrome://flags

chrome://flags/#automatic-fullscreen-content-setting

Finch feature name

AutomaticFullscreenContentSetting

Requires code in //chrome?

True (Chrome settings pages, page info bubble, enterprise policy integration)

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1501130

Launch bug

https://launch.corp.google.com/launch/4296344

Measurement

Blink.UseCounter.Features: FullscreenAllowedByContentSetting https://chromestatus.com/metrics/feature/timeline/popularity/4835

Availability expectation

Feature is available only in Chromium browsers for the foreseeable future

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome

Sample links

https://github.com/michaelwasserman/iwa-windowing-example

Estimated milestones

Shipping on desktop 126

DevTrial on desktop 124

Anticipated spec changes

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture#spec-changes

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6218822004768768

Links to previous Intent discussions

I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/CuIqA2v3cvs/m/C6J3clNxAAAJ

This intent message was generated by Chrome Platform Status.

[Vladimir Levin]

Does this change also need to update the referenced spec? In the spec, it seems like if there is no transient activation, it results in an error. I'm trying to understand whether (and how) the spec needs to be updated to reflect the capability proposed in this intent

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVwU7-73Mux5N-0DwYHNC34d8W5z4Yrfy6Qa_if%3DDxCsQ%40mail.gmail.com.

[Mike Wasserman]

Yes, there's a draft PR with the Explainer's anticipated spec changes, which are designed alike The rules for choosing a navigable when a new top-level traversable is being requested, as invoked by Window.open():

• If currentNavigable's active window does not have transient activation and the user agent has been configured to not show popups (i.e., the user agent has a "popup blocker" enabled)
  • The user agent may inform the user that a popup has been blocked.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Vladimir Levin]

Ah thanks, I missed it in the explainer. The spec changes make sense to me. The changes don't look like they would be controversial, but it's probably worthwhile to ensure that this PR is under review and/or landing as a part of shipping this.

Thanks!

Vlad

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVwU7-73Mux5N-0DwYHNC34d8W5z4Yrfy6Qa_if%3DDxCsQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b8910e6-5c31-4a00-8638-3d6a2a1632d9n%40chromium.org.

[Mike Wasserman]

Sure. I'll note that whatwg/fullscreen's PR merging includes a question or criteria "At least two implementers are interested (and none opposed)".

I have filed standards position requests with Mozilla and WebKit, and I will ping fullscreen spec maintainers for input.

[Mike Taylor]

It would be nice for the PR to be reviewed and approved, even without other stakeholder support.

Additionally - the explainer mentions a few options for feature detection. Any progress on that front? Or is it just hypothetical?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpXQRXW_Z2LzdQ%3DSTBf2aLydwrD5TT51XR3qrg4zYT8Nig%40mail.gmail.com.

[Mike Wasserman]

Thanks! I pinged the PR, and hope for some feedback there soon.

Feature detection via Permissions API querying seems like a great follow up here, ideally alongside broadened feature availability (i.e. extending user control beyond Isolated Web Apps).

[Alex Russell]

Will the status of the permission be reflected in the Permissions API? I see Permissions Policy integration, but not the Permissions API reflection that I'd expect.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVwU7-73Mux5N-0DwYHNC34d8W5z4Yrfy6Qa_if%3DDxCsQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b8910e6-5c31-4a00-8638-3d6a2a1632d9n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Wasserman]

No, this content setting does not have Permissions API integration at this time.

That seems like a great future improvement, especially if user control of the setting is extended to more contexts.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVwU7-73Mux5N-0DwYHNC34d8W5z4Yrfy6Qa_if%3DDxCsQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b8910e6-5c31-4a00-8638-3d6a2a1632d9n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike Wasserman]

Our team can commit to adding Permissions API query integration, with the requisite approvals.

That would provide feature detection, and also clarify requestFullscreen method steps in the spec.

I'm requesting approval to ship the feature in its current state, given our commitment to follow up.

Thanks,

Mike

[Reilly Grant]

LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required according to the IWA-specific API launch process).

Thank you for working with the IWA and Security reviewers to figure out the right restrictions to prevent this from exacerbating fullscreen-based phishing attacks. We have the option to loosen these restrictions if a better UX solution to the notice and consent is developed. 

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

You received this message because you are subscribed to the Google Groups "iwa-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iwa-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/iwa-dev/CAEsbcpWxbi-Dwzhr_%3DSYjw%2BWas0qXEtk6ACLV%3DbthJ5RW8GDbw%40mail.gmail.com.

[Mike Taylor]

LGTM1, with the commitment to follow up on Permissions API integration (thanks!).

[Vladimir Levin]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5bdf8737-200a-4d16-a621-e598f3f47740%40chromium.org.

[Philip Jägenstedt]

Hi Mike,

I think the use cases here are clear and skipping the user activation requirement is the only way to meet them. I believe that the biggest risk here is content written assuming this setting not working without it, and it being hard to understand why. In other words, debuggability and feature detection. Thank you for committing to the Permissions API query integration, that and good error messages addresses this risk.

Thanks for also working on the spec for this. If this was a change to default behavior I'd want to await more input, but it's not, and the fact that this feature is only available to specific apps and origins massively reduces the risk that content on the web broadly comes to depend on this and breaks in other browsers.

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MfuX1Gkg_DGTFmznD3wGsZZH66zccx78w2s66%3DYcj-Ww%40mail.gmail.com.