Contact emails [email protected]
Explainer https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture Specification https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen Design docs Internal; will expand Explainer during prototyping. https://docs.google.com/document/d/1yO5Ixgp6VNfYpGrqxezUmLaM-g_ZPGb16bxQ6_q9ln4 Summary A new "Automatic Fullscreen" content setting permits Element.requestFullscreen() without a user gesture [1]. The setting is blocked by default. Users can allow Isolated Web Apps [2], and enterprise admins can allow additional origins. 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] Also window.open()'s experimental 'fullscreen' feature; see https://chromestatus.com/feature/6002307972464640 <https://chromestatus.com/feature/6002307972464640> [2] User control is initially scoped to security-sensitive apps; see https://chromestatus.com/feature/5146307550248960 <https://chromestatus.com/feature/5146307550248960> [3] For multi-screen window placement features; see https://chromestatus.com/feature/5252960583942144 <https://chromestatus.com/feature/5252960583942144> [4] To waive window.open()'s own user gesture requirements; see chrome://settings/content/popups Blink component Blink>Fullscreen <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFullscreen> Motivation Some web apps (e.g. finance, gaming, point-of-sale, signage, and presentation) require multi-screen fullscreen from one gesture. Virtual Desktop Infrastructure (VDI) clients also require fullscreen without a gesture to: - Automatically extend a fullscreen desktop session onto a newly connected display - 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 - Restore fullscreen on local display changes, local user session unlocks, other local OS Window Manager interruptions Initial public proposal https://github.com/whatwg/fullscreen/issues/234 Search tagsFullscreen <https://chromestatus.com/features#tags:Fullscreen>, requestFullscreen <https://chromestatus.com/features#tags:requestFullscreen> , transient activation <https://chromestatus.com/features#tags:transient%20activation>, user gesture <https://chromestatus.com/features#tags:user%20gesture>, content setting <https://chromestatus.com/features#tags:content%20setting> TAG review N/A; this is not proposing a new or changed web API, but a browser-specific permission configuration. RisksInteroperability 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 & WebKit: N/A; this is not proposing a new or changed web API, but a browser-specific permission configuration. 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 ErgonomicsThe explainer discusses potential feature detection methods. 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 Debuggability Sites can debug via Element.requestFullscreen()'s promise, which may reject with a TypeError containing a message, supplemented by 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. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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; for content settings and enterprise policy management. 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: kFullscreenAllowedByContentSetting Adoption expectation Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome Sample linkshttps://github.com/michaelwasserman/iwa-windowing-example Estimated milestones Shipping on desktop 126 DevTrial on desktop 123 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6218822004768768 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVr%3D_jTt_fCPBFXkTKW4yatLKNoe_KTrvp47fzdCqdHWw%40mail.gmail.com.
