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). > - 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. > > --diego > > On Friday, 19 November 2021 at 06:05:44 UTC yoav...@chromium.org 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 <die...@gmail.com> 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: ajayra...@google.com >>>>> >>>>> 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 yoav...@chromium.org >>>>>> 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 <die...@gmail.com> >>>>>>> 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 yoav...@chromium.org >>>>>>>> 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 < >>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>> >>>>>>>>>>> amb...@microsoft.com, luig...@microsoft.com, >>>>>>>>>>> hat...@microsoft.com, c...@chromium.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 blink-dev+...@chromium.org. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6169866-631a-491d-8adf-5e720f48e48an%40chromium.org.
