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).
On Tue, May 14, 2024 at 1:43 PM Mike Taylor <miketa...@chromium.org> wrote: > 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? > On 5/9/24 3:04 PM, Mike Wasserman wrote: > > 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. > > On Thu, May 9, 2024 at 11:39 AM Vladimir Levin <vmp...@chromium.org> > wrote: > >> 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 >> >> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman <m...@chromium.org> wrote: >> >>> Yes, there's a draft PR <https://github.com/whatwg/fullscreen/pull/235> >>> with the Explainer's anticipated spec changes >>> <https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture#spec-changes>, >>> which are designed >>> <https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture?tab=readme-ov-file#detailed-design-discussion> >>> alike The rules for choosing a navigable >>> <https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable> >>> when a new top-level traversable >>> <https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-traversable> >>> is being requested, as invoked by Window.open() >>> <https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-open-dev>: >>> >>> >>> - If currentNavigable's active window >>> >>> <https://html.spec.whatwg.org/multipage/document-sequences.html#nav-window> >>> does not have transient activation >>> >>> <https://html.spec.whatwg.org/multipage/interaction.html#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. >>> >>> >>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote: >>> >>>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman <m...@chromium.org> wrote: >>>> >>>>> 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFullscreen> >>>>> >>>>> Search tags >>>>> >>>>> Fullscreen <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. >>>>> >>>> >>>> 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 >>>> >>>> >>>>> 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 >>>>> <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 (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 >>>>> <https://chromestatus.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+unsubscr...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVwU7-73Mux5N-0DwYHNC34d8W5z4Yrfy6Qa_if%3DDxCsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b8910e6-5c31-4a00-8638-3d6a2a1632d9n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpXQRXW_Z2LzdQ%3DSTBf2aLydwrD5TT51XR3qrg4zYT8Nig%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEsbcpVHcR_X8FuqnT_Qom9GHh6iOukGRscJ8SXkRvvUwjz7bg%40mail.gmail.com.
