After a bit more consideration and consultation with a colleague, the WebView team isn't overly concerned about the ultimate choice that's taken here for this specific feature/API on WebView. One can make a reasonable case for either course of action.
It is still a somewhat unusual case, so it might be best to avoid using this case as a precedent for unrelated features. The modern I2S process typically asks to clarify the WebView story anyway, but this feature dates back 4 years and didn't benefit from that. Ashley Newson On Wednesday, 26 November 2025 at 01:26:42 UTC Ashley Newson wrote: > Just to be clear, I'm not an authority on feature launch decisions. I > merely keep an eye out for unintentional/undocumented changes to WebView's > Web API surface where the compatibility story can be a little more complex. > > On Tue, 25 Nov 2025, 21:31 David Baron, <[email protected]> wrote: > >> As an outside observer (but one who was a bit involved in drafting current >> web platform guidance on feature detection >> <https://www.w3.org/TR/design-principles/#feature-detect> a number of >> years ago), I think Nate's approach of enabling for WebView seems like the >> right path for this feature given its current design. The feature handles >> platform differences within the feature itself, and it makes sense for >> Android WebView to behave the same as other platforms do for web content >> outside of a PWA with window-controls-overlay display mode (which I think >> is the vast majority of web content). I think one could make a reasonable >> argument in either direction on whether navigator.windowControlsOverlay >> should be exposed when the API isn't relevant. But once that decision is >> made we should stick to it: distinguishing Android WebView from all the >> other cases where the API is not relevant seems like an unnecessary >> distinction that creates differences in web platform implementation where >> they are not needed (and thus harmful due to increased risk of content >> that's broken for some of the cases). >> >> -David >> >> On Tue, Nov 25, 2025 at 4:00 PM 'Ashley Newson' via blink-dev < >> [email protected]> wrote: >> >>> A common practice on the Web is to perform feature detection by checking >>> whether or not the APIs are defined. The visibility of these APIs to >>> JavaScript may imply that the feature is available when it is not. >>> Additionally, as the API won't be maintained or well-tested on a platform >>> that it doesn't support, disabling the feature may avoid potential future >>> bugs. The safer option is to keep the feature disabled on Android WebView. >>> (And if WebView has not been intentionally scoped within the launch, it's >>> also more appropriate.) >>> >>> This should be straightforward to achieve by appending an entry to >>> //android_webview/browser/aw_field_trials.cc to disable the Blink feature >>> and then re-updating the web exposed expectations. (E.g. >>> `aw_feature_overrides.DisableFeature(blink::features::kWindowControlsOverlay);`) >>> >>> Feel free to reach out if you require any assistance with this. >>> >>> Ashley Newson >>> On Tuesday, 25 November 2025 at 19:23:34 UTC Nate Chapin wrote: >>> >>>> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -- 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/eba95e74-a958-4058-b007-f0de31615badn%40chromium.org.
