LGTM2 On Tue, Dec 7, 2021 at 2:36 AM Yoav Weiss <yoavwe...@chromium.org> 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 luig...@microsoft.com >> 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 yoav...@chromium.org >>>> 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 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/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 blink-dev+unsubscr...@chromium.org. 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.
