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/CAB1e-0eVqob7RYPSYAXZTHYW4b9KwrgNjL-uG_LjP%2B9iDB3n3w%40mail.gmail.com.
