There are two parts to Window Controls Overlay: How it changes the window controls, and the `navigator.windowControlsOverlay` API.
You are correct that the changes to the window controls are irrelevant to Android WebView (WebView isn't used for PWAs, and Window Controls Overlay is only relevant to PWAs). What you saw in http://crrev.com/c/7197647 is exposing the `navigator.windowControlsOverlay` API on Android WebView. This matches other platforms outside of a PWA with `window-controls-overlay` windowing mode: the `navigator.windowControlsOverlay` API is exposed, but `navigator.windowControlsOverlay.visible` returns false, no events are fired, and `navigator.windowControlsOverlay.getTitlebarAreaRect()` returns an empty DOMRect. I agree it's a little strange to expose this in Android WebView when it will never return anything other than the default values, but we believe that is most consistent with how the API surface is exposed on other platforms. Thanks, ~Nate On Tue, Nov 25, 2025 at 10:17 AM Ashley Newson <[email protected]> wrote: > > Hello, > > I spotted crrev.com/c/7197647 in my watchlist. It modifies Android > WebView's stable Web Exposed expectations > (//android_webview/test/data/web_tests/virtual/stable/webexposed/global-interface-listing-expected.txt) > indicating that this API will become visible to JavaScript in Android > WebView-based apps. > > I can't find any information to suggest that WebView supports this > feature. From the feature's description, it doesn't sound like it could > ever apply to WebView, as WebView doesn't have window controls (or much > other browser UI in general). Can you confirm what the intended WebView > story is here? > > Ashley Newson > On Monday, 24 November 2025 at 21:31:01 UTC Nate Chapin wrote: > >> PSA: We've been working on building out Window Controls Overlay support on >> Android <https://chromestatus.com/feature/5184275368509440> when desktop >> windowing is enabled, and we're planning on shipping it in M144 >> <https://chromium-review.googlesource.com/c/chromium/src/+/7197647>. >> ~Nate >> >> On Wednesday, December 15, 2021 at 1:52:52 AM UTC-8 Daniel Bratell wrote: >> >>> I don't see our shipping decision as being limited to any particular >>> platform, except that mobile was excluded by the "desktop web apps" title >>> so you go ahead and ship for ChromeOS as well. >>> >>> /Daniel >>> On 2021-12-15 09:06, 'Sonja Laurila' via blink-dev wrote: >>> >>> Hey, >>> >>> This feature has also been implemented for ChromeOS and I was wondering >>> if it needs a separate I2S or if it should go with this same one? >>> >>> Most of the WML implementation worked for CrOS already just by adding >>> CrOS to the about flag definition and to the directive conditions, e.g. >>> reading the CSS attributes etc. The missing parts of the CrOS >>> implementation can be found on this CL: https://crrev.com/c/3204967/ >>> (was later enabled for LaCrOS also: https://crrev.com/c/3240745). The >>> implementation is fairly similar to the implementation for W&L. The only >>> missing piece of the puzzle for CrOS atm is that it is still not included >>> in runtime_enabled_features.json5 >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;drc=a1e6a0738c2ba99308d5473e634e0d546e23368f;l=2486> >>> . >>> >>> So just to follow the processes, what would be the next steps to get the >>> CrOS side ship as well? :) >>> >>> Best regards, >>> Sonja Laurila >>> >>> >>> >>> On Thursday, December 9, 2021 at 9:58:02 PM UTC+2 [email protected] >>> wrote: >>> >>>> Great! >>>> >>>> LGTM3 >>>> >>>> On 12/9/21 2:27 PM, Diego González wrote: >>>> >>>> Hola Mike, >>>> >>>> That is a very valid point. We've renamed the boundingRect attribute to >>>> titlebarAreaRect to remove any ambiguity regarding the area being >>>> referenced. >>>> >>>> The change has now been merged. Thanks! >>>> >>>> Diego >>>> >>>> >>>> On Thursday, 9 December 2021 at 14:33:09 UTC [email protected] >>>> wrote: >>>> >>>>> I did, but ran out of time before sending an email last night. :) >>>>> >>>>> I see that getBoundingClientRect was renamed to getTitleBarRect >>>>> <https://github.com/WICG/window-controls-overlay/commit/a37a4a2d040383159f05e9466425b18749146081#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R227>, >>>>> would it make sense to update the boundingRect attribute on the geometry >>>>> change event as well, or do you think boundingRect is still the right >>>>> name? >>>>> >>>>> On 12/9/21 4:29 AM, Mike West wrote: >>>>> >>>>> I believe @Mike Taylor had some questions around spelling decisions >>>>> in the API in our last API owners meeting. Mike, did you have a chance to >>>>> look into that more deeply? >>>>> >>>>> -mike >>>>> >>>>> >>>>> On Wed, Dec 8, 2021 at 11:00 PM Chris Harrelson <[email protected]> >>>>> wrote: >>>>> >>>>>> LGTM2 >>>>>> >>>>>> On Tue, Dec 7, 2021 at 2:36 AM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> *LGTM1* >>>>>>> Thanks for driving those discussions and making the spec >>>>>>> interoperable in the process. >>>>>>> >>>>>>> On Tuesday, December 7, 2021 at 11:07:21 AM UTC+1 Diego González >>>>>>> wrote: >>>>>>> >>>>>>>> Just as a heads up, all concerns have been addressed and the latest >>>>>>>> version of the spec is in a state where I believe we are all happy >>>>>>>> with. >>>>>>>> Thanks for all the feedback and comments! >>>>>>>> >>>>>>>> On Wednesday, 1 December 2021 at 18:26:03 UTC [email protected] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> There is a PR waiting to be merged that adds a note about >>>>>>>>> developers using reasonable fallbacks on unsupported browsers, I will >>>>>>>>> let >>>>>>>>> you know once it gets merged. >>>>>>>>> >>>>>>>>> On Wednesday, 1 December 2021 at 17:29:03 UTC Diego González wrote: >>>>>>>>> >>>>>>>>>> YUC. 😉 >>>>>>>>>> >>>>>>>>>> If a developer has used the environmental variables and the web >>>>>>>>>> app gets installed in browser that does not support it (then it is a >>>>>>>>>> parallel universe because Firefox nor Safari nor other desktop >>>>>>>>>> browser >>>>>>>>>> supports this *kidding*) then they can specify reasonable fallback >>>>>>>>>> values >>>>>>>>>> because they value progressive enhancement and responsive design. I >>>>>>>>>> will >>>>>>>>>> add a note about this to the spec, if you think it is necessary. >>>>>>>>>> >>>>>>>>>> Lack of WCO support and lack of user opt in do not look the same. >>>>>>>>>> In a supported browser both the env variables and the JS object in >>>>>>>>>> navigator exist even if the feature is turned off. >>>>>>>>>> >>>>>>>>>> On Wednesday, 1 December 2021 at 11:11:03 UTC >>>>>>>>>> [email protected] wrote: >>>>>>>>>> >>>>>>>>>>> On Tuesday, November 30, 2021 at 6:48:07 PM UTC+1 Diego González >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hola Yoav, >>>>>>>>>>>> >>>>>>>>>>>> I wanted to add that we implemented the concept of a >>>>>>>>>>>> display-override to control the fallback of display modes. For non >>>>>>>>>>>> supported browsers, developers can also specify the >>>>>>>>>>>> display-override and >>>>>>>>>>>> even if this is not supported it will default to the display value >>>>>>>>>>>> in the >>>>>>>>>>>> manifest file. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Monday, 29 November 2021 at 18:29:41 UTC Diego González >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hola Yoav, >>>>>>>>>>>>> >>>>>>>>>>>>> For non supported browsers there are 2 options: >>>>>>>>>>>>> >>>>>>>>>>>>> - env variables take the specified default value by >>>>>>>>>>>>> developers (if devs enable WCO). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> So IIUC developers are supposed to use the env variables with >>>>>>>>>>> reasonable fallback values for non-supporting browsers? Is that >>>>>>>>>>> advice >>>>>>>>>>> captured/documented somewhere? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> - The web app will open as it would in the browser, with a >>>>>>>>>>>>> titlebar if installed (if devs don't enable WCO). >>>>>>>>>>>>> >>>>>>>>>>>>> WCO is enabled by the end user. The user must enable the >>>>>>>>>>>>> feature by toggling the chevron on the controls overlay. This is >>>>>>>>>>>>> remembered >>>>>>>>>>>>> on subsequent app launches. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> OK, so lack of WCO support by the browser and lack of user >>>>>>>>>>> opt-in would look the same from the developer's perspective? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> --diego >>>>>>>>>>>>> >>>>>>>>>>>>> On Friday, 19 November 2021 at 06:05:44 UTC >>>>>>>>>>>>> [email protected] wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> This looks great! Thanks for following up on the spec work!! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I had a couple more questions upthread: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - What are developers expected to do in non-supporting >>>>>>>>>>>>>> browsers? >>>>>>>>>>>>>> - Would the user need to opt-in to having web app control >>>>>>>>>>>>>> over their title bar? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Nov 19, 2021 at 1:25 AM Diego González < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the the new *new* spec update >>>>>>>>>>>>>>> https://wicg.github.io/window-controls-overlay/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wednesday, 17 November 2021 at 19:06:24 UTC Diego >>>>>>>>>>>>>>> González wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hola, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> See the updated spec here: >>>>>>>>>>>>>>>> https://wicg.github.io/window-controls-overlay. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Monday, 15 November 2021 at 17:00:34 UTC Ajay Rahatekar >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cc: [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Monday, November 15, 2021 at 8:53:37 AM UTC-8 Diego >>>>>>>>>>>>>>>>> González wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hola Yoav, I am looking at making the amendments listed >>>>>>>>>>>>>>>>>> on the github issues. I will update soon with the changes. >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Monday, 15 November 2021 at 08:44:41 UTC >>>>>>>>>>>>>>>>>> [email protected] wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks Diego! The updates are a great improvement, but I >>>>>>>>>>>>>>>>>>> suspect are not sufficient for an interoperable >>>>>>>>>>>>>>>>>>> implementation. I left a >>>>>>>>>>>>>>>>>>> couple of comments on the open issues. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Nov 10, 2021 at 5:11 PM Diego González < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hola Yoav, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We've gone through several iterations of the WCO spec >>>>>>>>>>>>>>>>>>>> reviewed by Joshua Bell from Google, and while we are >>>>>>>>>>>>>>>>>>>> still making changes >>>>>>>>>>>>>>>>>>>> to it, we believe it is in a much better state and want to >>>>>>>>>>>>>>>>>>>> resubmit for >>>>>>>>>>>>>>>>>>>> consideration of the approvals needed for I2S. See the >>>>>>>>>>>>>>>>>>>> updated spec below: >>>>>>>>>>>>>>>>>>>> https://wicg.github.io/window-controls-overlay/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --Diego >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Thursday, 21 October 2021 at 21:05:09 UTC+1 >>>>>>>>>>>>>>>>>>>> [email protected] wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Thursday, October 21, 2021 at 9:31:23 AM UTC+2 Yoav >>>>>>>>>>>>>>>>>>>>> Weiss wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This is an exciting improvement to PWA parity with >>>>>>>>>>>>>>>>>>>>>> native apps! :) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via >>>>>>>>>>>>>>>>>>>>>> blink-dev <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> [email protected], [email protected], >>>>>>>>>>>>>>>>>>>>>>> [email protected], [email protected] >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://wicg.github.io/window-controls-overlay/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The spec looks like it could use some work. Beyond >>>>>>>>>>>>>>>>>>>>>> the editorial, it doesn't seem like it defines the novel >>>>>>>>>>>>>>>>>>>>>> concepts that it >>>>>>>>>>>>>>>>>>>>>> introduces, nor the relevant processing models. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Let me expand on that a bit. The spec introduces a new >>>>>>>>>>>>>>>>>>>>> concept of a "window overlay" without really creating it >>>>>>>>>>>>>>>>>>>>> as a concept. >>>>>>>>>>>>>>>>>>>>> What I expect an interoperable spec to define the >>>>>>>>>>>>>>>>>>>>> concept with as much detail as possible without getting >>>>>>>>>>>>>>>>>>>>> OS- or >>>>>>>>>>>>>>>>>>>>> implementation-specific. >>>>>>>>>>>>>>>>>>>>> (Just to draw an example of what I have in mind, if I >>>>>>>>>>>>>>>>>>>>> had to make something up, I'd go with something like: >>>>>>>>>>>>>>>>>>>>> "<dfn>Window >>>>>>>>>>>>>>>>>>>>> overlay</dfn> is an interface element that the operating >>>>>>>>>>>>>>>>>>>>> system uses >>>>>>>>>>>>>>>>>>>>> consistently across applications to enable the user to >>>>>>>>>>>>>>>>>>>>> perform certain >>>>>>>>>>>>>>>>>>>>> action to control the application such as closing it, >>>>>>>>>>>>>>>>>>>>> expanding it to full >>>>>>>>>>>>>>>>>>>>> screen, etc. This UI element takes fixed dimensions....") >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Then, once you have that concept defined, you can >>>>>>>>>>>>>>>>>>>>> start building on it and define the processing of the >>>>>>>>>>>>>>>>>>>>> different methods >>>>>>>>>>>>>>>>>>>>> based on that. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'll open issues with other suggestions. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Window Controls Overlay allows a developer to create >>>>>>>>>>>>>>>>>>>>>>> a custom title bar UX by extending the installed app’s >>>>>>>>>>>>>>>>>>>>>>> client area. The >>>>>>>>>>>>>>>>>>>>>>> client area now covers the entire window except for the >>>>>>>>>>>>>>>>>>>>>>> window controls >>>>>>>>>>>>>>>>>>>>>>> (close, maximize/restore, minimize), which are overlaid >>>>>>>>>>>>>>>>>>>>>>> in their respective >>>>>>>>>>>>>>>>>>>>>>> position. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The web app developer is responsible for drawing and >>>>>>>>>>>>>>>>>>>>>>> input-handling for the entire window except for the >>>>>>>>>>>>>>>>>>>>>>> window controls >>>>>>>>>>>>>>>>>>>>>>> overlay. This includes defining which area of the >>>>>>>>>>>>>>>>>>>>>>> window is draggable as well, with a prefixed and >>>>>>>>>>>>>>>>>>>>>>> non-prefixed version of a >>>>>>>>>>>>>>>>>>>>>>> css property supported, as implemented in: >>>>>>>>>>>>>>>>>>>>>>> crrev.com/c/3094474. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Intended uses for the Window Controls Overlay are >>>>>>>>>>>>>>>>>>>>>>> creating seamless UX that can use the area that was >>>>>>>>>>>>>>>>>>>>>>> reserved for the title >>>>>>>>>>>>>>>>>>>>>>> bar before. Many modern applications include menus, >>>>>>>>>>>>>>>>>>>>>>> search bars and other >>>>>>>>>>>>>>>>>>>>>>> controls in the title bar, and this feature enables >>>>>>>>>>>>>>>>>>>>>>> this on installed web >>>>>>>>>>>>>>>>>>>>>>> apps. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> UI>Browser>WebAppInstalls >>>>>>>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Search tags >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> PWA <https://chromestatus.com/features#tags:PWA>, web >>>>>>>>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:web%20app>, >>>>>>>>>>>>>>>>>>>>>>> title >>>>>>>>>>>>>>>>>>>>>>> bar >>>>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:title%20bar>, >>>>>>>>>>>>>>>>>>>>>>> titlebar >>>>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:titlebar>, >>>>>>>>>>>>>>>>>>>>>>> customization >>>>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:customization>, >>>>>>>>>>>>>>>>>>>>>>> window controls >>>>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:window%20controls> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/481 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Resolution: satisfied >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Given that Edge has interest in the feature, there >>>>>>>>>>>>>>>>>>>>>>> would be at least one other browser that implements it. >>>>>>>>>>>>>>>>>>>>>>> The feature >>>>>>>>>>>>>>>>>>>>>>> involves additive changes (new web app manifest entry, >>>>>>>>>>>>>>>>>>>>>>> new JS API, new CSS >>>>>>>>>>>>>>>>>>>>>>> env variables) and modifications (changes to frame, new >>>>>>>>>>>>>>>>>>>>>>> use of >>>>>>>>>>>>>>>>>>>>>>> env(safe-area-inset-*), but no removals, so the >>>>>>>>>>>>>>>>>>>>>>> compatibility risk is >>>>>>>>>>>>>>>>>>>>>>> minimal. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Gecko: defer >>>>>>>>>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/529 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> WebKit: No signal >>>>>>>>>>>>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031865.html >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Web developers: Positive >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/firt/status/1385238446046859268?s=20 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/AnaestheticsApp/status/1408727417330573314?s=20 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/bashik7/status/1385821988208275457?s=20 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/abraham/status/1385201046767738880?s=20 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The changes associated with this feature will only >>>>>>>>>>>>>>>>>>>>>>> be enabled for PWAs that opt-in to it, so there are >>>>>>>>>>>>>>>>>>>>>>> minimal risks posed to >>>>>>>>>>>>>>>>>>>>>>> the browser as a whole. A PWA that opts-in to the >>>>>>>>>>>>>>>>>>>>>>> feature should also have >>>>>>>>>>>>>>>>>>>>>>> minimal ergonomics risk since the manifest already >>>>>>>>>>>>>>>>>>>>>>> needs to be parsed on >>>>>>>>>>>>>>>>>>>>>>> startup to determine the correct display mode in which >>>>>>>>>>>>>>>>>>>>>>> the app should be >>>>>>>>>>>>>>>>>>>>>>> launched, so adding one extra manifest check on startup >>>>>>>>>>>>>>>>>>>>>>> should have minimal >>>>>>>>>>>>>>>>>>>>>>> impact. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Activation >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The activation risk is low since this feature >>>>>>>>>>>>>>>>>>>>>>> includes all the tools needed to create an app that >>>>>>>>>>>>>>>>>>>>>>> uses the full extent of >>>>>>>>>>>>>>>>>>>>>>> the window: new UA-provided window controls overlay, JS >>>>>>>>>>>>>>>>>>>>>>> APIs to query the >>>>>>>>>>>>>>>>>>>>>>> size of the overlay, and CSS environment variables to >>>>>>>>>>>>>>>>>>>>>>> layout content around >>>>>>>>>>>>>>>>>>>>>>> the overlay. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What do we expect developers to do as a fallback in >>>>>>>>>>>>>>>>>>>>>> non-supporting browsers? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Security >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The major risk is that giving sites partial control >>>>>>>>>>>>>>>>>>>>>>> over the top of the app window allows developers to >>>>>>>>>>>>>>>>>>>>>>> spoof content in what >>>>>>>>>>>>>>>>>>>>>>> was previously a trusted, UA-controlled region. To >>>>>>>>>>>>>>>>>>>>>>> minimize the risk of >>>>>>>>>>>>>>>>>>>>>>> spoofing, the app will open by default in “standalone” >>>>>>>>>>>>>>>>>>>>>>> mode with a full >>>>>>>>>>>>>>>>>>>>>>> width title bar, and the user can toggle window >>>>>>>>>>>>>>>>>>>>>>> controls overlay on and off >>>>>>>>>>>>>>>>>>>>>>> via a button in the title bar/overlay. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> OK, so both the app *and* the user need to opt-in? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The feature itself can be easily debugged by >>>>>>>>>>>>>>>>>>>>>>> installing the PWA. Since it is a visual feature on the >>>>>>>>>>>>>>>>>>>>>>> window itself, it >>>>>>>>>>>>>>>>>>>>>>> is easy to test. Nonetheless, making sure parsing the >>>>>>>>>>>>>>>>>>>>>>> “display-override” >>>>>>>>>>>>>>>>>>>>>>> mode and associated values correctly is desired, which >>>>>>>>>>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>>>>>>>>> incorporated into the application tab of devtools, >>>>>>>>>>>>>>>>>>>>>>> where all the other >>>>>>>>>>>>>>>>>>>>>>> manifest warnings are displayed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3170531: dpwas: WPT Tests for >>>>>>>>>>>>>>>>>>>>>>> window-controls-overlay | >>>>>>>>>>>>>>>>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/3170531 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Flag name >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> #enable-desktop-pwas-window-controls-overlay >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> False >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=937121 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://crbug.com/1108107 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Sample links >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://amandabaker.github.io/pwa/explainer-example/index.html >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> OriginTrial desktop last >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 96 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> OriginTrial desktop first >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 93 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Expected Release >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 97 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5741247866077184 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/cper6nNLFRQ/hU91kfCWBQAJ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/HNHbpxvrECA/m/JJoXKQI3BAAJ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> This intent message was generated by Chrome >>>>>>>>>>>>>>>>>>>>>>> Platform Status <https://www.chromestatus.com/>. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *Diego González-Zúñiga* >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> PM, Microsoft Edge >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> 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/VI1PR83MB041666BD26451656C388347CCCBE9%40VI1PR83MB0416.EURPRD83.prod.outlook.com >>>>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/VI1PR83MB041666BD26451656C388347CCCBE9%40VI1PR83MB0416.EURPRD83.prod.outlook.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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a31d3e96-fb01-45c4-b979-2f04cfdb06fdn%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a31d3e96-fb01-45c4-b979-2f04cfdb06fdn%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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8bNbLih3qqn%2B%3DEAx%2B8TiLScqM7RuR9-C%3DjfmacHnDYcA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8bNbLih3qqn%2B%3DEAx%2B8TiLScqM7RuR9-C%3DjfmacHnDYcA%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 [email protected]. >>> >>> >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a94d9d91-9686-485c-bf83-8d490a427b4en%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a94d9d91-9686-485c-bf83-8d490a427b4en%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LKDc8fawn%3D_bnQzfg3R12wx2yC96Z3eAcsbWZrji-fEKg%40mail.gmail.com.
