LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required according to the IWA-specific API launch process <https://www.chromium.org/blink/launching-features/isolated-web-apps/>).
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 | reil...@chromium.org | Google Chrome <https://www.google.com/chrome> On Wed, May 15, 2024 at 3:00 PM Mike Wasserman <m...@chromium.org> wrote: > 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 > "iwa-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to iwa-dev+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/iwa-dev/CAEsbcpWxbi-Dwzhr_%3DSYjw%2BWas0qXEtk6ACLV%3DbthJ5RW8GDbw%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/CAEmk%3DMaxuVfJp7-aG%2BQof01h4rujTVEoj1fDV7af3xC%2B-QqUGw%40mail.gmail.com.
