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 On Wed, May 15, 2024 at 10:01 AM Mike Wasserman <m...@chromium.org> wrote: > 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. > > On Wed, May 15, 2024 at 9:37 AM Alex Russell <slightly...@chromium.org> > wrote: > >> 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 >> >> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote: >> >>> 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/CAEsbcpWxbi-Dwzhr_%3DSYjw%2BWas0qXEtk6ACLV%3DbthJ5RW8GDbw%40mail.gmail.com.
