Thanks Thomas, looking forward to being able to say LGTM to this :) I agree that it would be ideal if the unprefixed API is supported on iOS before we remove the video-specific prefixed APIs in Chrome, so that people can have confidence their updated code will work in both Chrome and Safari.
On Mon, Jan 29, 2024 at 8:43 PM Thomas Guilbert <tguilb...@google.com> wrote: > Ok for a 6 months trial, with the possibility to extend it further. I will > wait for the remaining security/privacy approvals and then update this > thread again. > > Additionally, someone commented on the WebKit positions standards thread > <https://github.com/WebKit/standards-positions/issues/306#issuecomment-1911106462> > that > the next version of Safari will have support for the fullscreen API (still > subject to change before shipping). It would be great timing if the API > ships on iOS, to minimize the work for web authors as they switch away from > the API. > > On Fri, Jan 26, 2024 at 6:26 AM Philip Jägenstedt <foo...@chromium.org> > wrote: > >> https://sites.google.com/a/chromium.org/dev/blink/launching-features >> doesn't give any guidance on the timeline, so let's just pick a timeline >> that makes sense for this case. It's been up to a year in other cases. >> >> Since feature detection is common, we have to remove the whole API >> surface and let code that depends on it throw exceptions. We won't be able >> to print anything helpful to the console informing developers that there is >> a deprecation trial. From their point of view it will simply be removed, >> and they might find out about the deprecation trial if they do some further >> research. >> >> Since the cost of supporting these APIs is very low, I think we >> should give developers plenty of time. But usage is already so low that >> it's not a certainty that anyone will really use the trial. So how about we >> start with 6 months, and if we see that there are sites using the trial to >> re-enable the feature, then we extend it by another 6 months. Would that >> work? >> >> On Thu, Jan 25, 2024 at 9:22 PM Thomas Guilbert <tguilb...@chromium.org> >> wrote: >> >>> Thank you Wesley for the useful information! >>> >>> > What timeline do you have in mind? >>> I'm not sure what reasonable timelines are, not having dealt with >>> deprecations before. Is 3 months for a deprecation trial acceptable? >>> Devtools should already have deprecation warnings >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/generated/Deprecation.ts;l=164;drc=44db243e9d23fa831e59175b1281360404cb31ac>, >>> but I don't see them in my console. >>> >>> I had looked at the only site listed for the >>> https://chromestatus.com/metrics/feature/timeline/popularity/170 >>> use-counter. They are directly calling the API for their overlay welcome >>> video, but the page seemed to work fine with the API disabled. I don't >>> think the fullscreen actually happens, without the user interaction... >>> >>> This use counter shows a spike up from December to January >>> https://chromestatus.com/metrics/feature/timeline/popularity/168. 5 >>> links are using https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js, >>> one link is also playing an overlay video intro. >>> >>> On Thu, Jan 25, 2024 at 12:25 AM Philip Jägenstedt <foo...@chromium.org> >>> wrote: >>> >>>> I'm also happy to support a plan to deprecate and remove. The use >>>> counter that best represents worst-case user impact at >>>> https://chromestatus.com/metrics/feature/timeline/popularity/170 at >>>> ~0.001%. But that's only when fullscreen actually happens (on user >>>> interaction) and it's very hard to say what proportion of sites could >>>> *potentially* hit this code path, especially given the ubiquitous >>>> pattern of trying multiple API names that's been necessary forever with >>>> fullscreen, so that some sites will just fall back to a working API. >>>> >>>> What timeline do you have in mind? >>>> >>>> On Thu, Jan 25, 2024 at 2:19 AM Domenic Denicola <dome...@chromium.org> >>>> wrote: >>>> >>>>> Thanks Thomas for all your work here! Your HTTP Archive survey seems >>>>> promising to me: it sounds like there are no regressions, and you found >>>>> some great places to perform outreach. (Hi Wesley!) >>>>> >>>>> I'm happy to LGTM this as soon as the privacy/security reviews are >>>>> approved and you've picked a target experiment timeline. >>>>> >>>>> On Thu, Jan 25, 2024 at 10:00 AM Wesley Luyten <luytenwes...@gmail.com> >>>>> wrote: >>>>> >>>>>> Wesley from Mux here. I saw the issue come by. >>>>>> >>>>>> We'd be happy those API's could get deprecated and unified into the >>>>>> new one. >>>>>> >>>>>> Our Media Chrome (library, not browser) implementation handles this >>>>>> gracefully, some code here >>>>>> >>>>>> https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636 >>>>>> >>>>>> The Vimeo player uses a variant of >>>>>> https://github.com/bdougherty/BigScreen, a similar popular library >>>>>> is https://github.com/sindresorhus/screenfull >>>>>> >>>>>> Just thought to mention it but iOS never supported the generic >>>>>> fullscreen API until very recent >>>>>> https://twitter.com/jensimmons/status/1717937227190460797 >>>>>> It always required the webkit prefixed API on the video element (not >>>>>> any other element like a div etc ) >>>>>> Y'all are aware of that? >>>>>> On Wednesday, January 24, 2024 at 6:23:16 PM UTC-6 Thomas Guilbert >>>>>> wrote: >>>>>> >>>>>>> I opened a support ticket with Mux, and opened an issue for Clappr >>>>>>> <https://github.com/clappr/clappr/issues/2136>. >>>>>>> >>>>>>> On Wed, Jan 24, 2024 at 3:40 PM Thomas Guilbert < >>>>>>> tgui...@chromium.org> wrote: >>>>>>> >>>>>>>> I've created a new ChromeStatus entry >>>>>>>> <https://chromestatus.com/feature/5111638103687168>, and requested >>>>>>>> the privacy/security/debuggability gates for the deprecation trial. >>>>>>>> >>>>>>>> I audited a little more than 20 sites from the HTTP Archive. I've >>>>>>>> found a few JS player libraries that primarily use the >>>>>>>> `webkitSupportsFullscreen` and `webkitDisplayingFullscreen` APIs: Mux >>>>>>>> and >>>>>>>> Clappr, and one instance of PlayerJS. >>>>>>>> I found websites with a fullscreen button for Mux and PlayerJS, and >>>>>>>> they behaved as expected on a build of Chrome without the APIs. The one >>>>>>>> site I found using Clappr that had a fullscreen button did not work, >>>>>>>> both >>>>>>>> on the custom build and the latest canary. >>>>>>>> >>>>>>>> It also seems like some version of the Vimeo CDN player uses >>>>>>>> `webkitEnterFullscreen`: >>>>>>>> https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js*.* >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Thomas >>>>>>>> >>>>>>>> On Mon, Jan 22, 2024 at 5:31 PM Domenic Denicola < >>>>>>>> dom...@chromium.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert < >>>>>>>>> tgui...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Good point about the most used APIs being the boolean properties! >>>>>>>>>> The APIs are now only aliases for the standard non-prefixed >>>>>>>>>> fullscreen APIs >>>>>>>>>> (see this code for the current implementation >>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/media/html_video_element.cc;l=418;drc=25705537e65f031d28c1a531046b11914055b7e6>), >>>>>>>>>> and therefore aren't much of a burden to maintain. >>>>>>>>>> >>>>>>>>>> I opened a WebKit standards position here: >>>>>>>>>> https://github.com/WebKit/standards-positions/issues/306 >>>>>>>>>> >>>>>>>>>> I unfortunately do not have access to edit the listed >>>>>>>>>> ChromeStatus entry, and the current owner no longer works on >>>>>>>>>> Chromium. >>>>>>>>>> Should I create a new feature (titled "Deprecation of >>>>>>>>>> HTMLVideoElement-specific Prefixed Fullscreen API")? I think the >>>>>>>>>> current >>>>>>>>>> ChromeStatus entry also covers this API >>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fullscreen/element_fullscreen.idl;l=19;drc=047c7dc4ee1ce908d7fea38ca063fa2f80f92c77> >>>>>>>>>> which I am not trying to deprecate in this Intent. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yeah, I think a new feature is a good idea. The old feature seems >>>>>>>>> to be for the *addition* of the prefixed fullscreen API >>>>>>>>> properties back in Chrome 15, whereas a *deprecation/removal* has >>>>>>>>> a different set of fields, if I understand correctly. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> What's a reasonable sample size of HTTP Archive sites to audit? >>>>>>>>>> Should this be a complement/precursor to the proposed Deprecation >>>>>>>>>> Trial, or >>>>>>>>>> would this sampling be enough? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I recall +Philip Jägenstedt having done some computations in the >>>>>>>>> past based on what would actually be statistically significant. But, I >>>>>>>>> couldn't find them in this documentation >>>>>>>>> <https://www.chromium.org/blink/platform-predictability/compat-tools/> >>>>>>>>> (or >>>>>>>>> the linked document >>>>>>>>> <https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit#heading=h.1m1gg72jnnrt>). >>>>>>>>> So, I'll just state that I would be happy with 20 sites. >>>>>>>>> >>>>>>>>> I think the deprecation trial is a great complement to have in any >>>>>>>>> case, so I would treat this as a precursor. It's always safest to >>>>>>>>> have the >>>>>>>>> option for web developers to un-break their sites. The purpose of the >>>>>>>>> HTTP >>>>>>>>> Archive investigation is mostly to see if we can find major shared >>>>>>>>> patterns, to say things like "all sites using this code will be >>>>>>>>> broken" or >>>>>>>>> "all sites using this code will be slightly worse, but basically >>>>>>>>> fine", or >>>>>>>>> even "all sites using this open-source library will be broken, but we >>>>>>>>> can >>>>>>>>> send them a PR and that will create a clear upgrade path". >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Thomas >>>>>>>>>> >>>>>>>>>> On Sun, Jan 21, 2024 at 7:56 PM Domenic Denicola < >>>>>>>>>> dom...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> It would be very exciting to clean this up! I have some >>>>>>>>>>> questions that might help clarify the cost-benefit analysis. >>>>>>>>>>> >>>>>>>>>>> On Sat, Jan 20, 2024 at 6:43 AM Thomas Guilbert < >>>>>>>>>>> tgui...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Contact emails >>>>>>>>>>>> >>>>>>>>>>>> tgui...@chromium.org >>>>>>>>>>>> >>>>>>>>>>>> Explainer >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> Specification >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> There was an attempt in 2014 >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Bxe7DnDVRZ0/m/5K61HQPrNK4J> >>>>>>>>>>>> to deprecate and remove the HTMLVideoElement-specific Prefixed >>>>>>>>>>>> Fullscreen >>>>>>>>>>>> APIs. This meant removing the following APIs from HTMLVideoElement: >>>>>>>>>>>> >>>>>>>>>>>> readonly attribute boolean webkitSupportsFullscreen; >>>>>>>>>>>> readonly attribute boolean webkitDisplayingFullscreen; >>>>>>>>>>>> void webkitEnterFullscreen(); >>>>>>>>>>>> void webkitExitFullscreen(); >>>>>>>>>>>> // Note the different capitalization of the "S" in FullScreen. >>>>>>>>>>>> void webkitEnterFullScreen(); >>>>>>>>>>>> void webkitExitFullScreen(); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> How "expensive" is it to support these APIs? For example, if >>>>>>>>>>> some of them are just straight-up aliases of standard APIs, then the >>>>>>>>>>> benefit of removal might be low. Whereas if, for example, these >>>>>>>>>>> prefixed >>>>>>>>>>> "enter fullscreen" APIs have different behavior than the >>>>>>>>>>> standardized >>>>>>>>>>> requestFullscreen() API, then supporting the prefixed variants feels >>>>>>>>>>> expensive, and getting rid of them is more worthwhile. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> The overall usage of these APIs is low, and has trended >>>>>>>>>>>> downwards over time. Here are the latest usage numbers, as a % >>>>>>>>>>>> of total page loads: >>>>>>>>>>>> >>>>>>>>>>>> PrefixedVideoSupportsFullscreen: 0.025% >>>>>>>>>>>> PrefixedVideoDisplayingFullscreen: 0.082% >>>>>>>>>>>> PrefixedVideoEnterFullscreen: 0.001% >>>>>>>>>>>> PrefixedVideoExitFullscreen: 0.010% >>>>>>>>>>>> PrefixedVideoEnterFullScreen: 0.001% >>>>>>>>>>>> PrefixedVideoExitFullScreen: 0.000% >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It's notable that the highest counters are for the boolean >>>>>>>>>>> properties. That makes this slightly less risky, because removing >>>>>>>>>>> them will >>>>>>>>>>> cause them to return `undefined`, so code like `if >>>>>>>>>>> (videoEl.webkitSupportsFullscreen) { ... }` will just return false, >>>>>>>>>>> instead >>>>>>>>>>> of throwing an exception or similar. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> There has been an unfortunate uptick in the past 2 years for >>>>>>>>>>>> the two following APIs, which means that it's best to remove them >>>>>>>>>>>> now, >>>>>>>>>>>> before they see a wider adoption. These numbers might be going up >>>>>>>>>>>> because >>>>>>>>>>>> the prefixed APIs are also present on iOS. >>>>>>>>>>>> >>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/166 >>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/167 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was going to ask about if there are popular sites or libraries >>>>>>>>>>> using these, but I found some discussion of that in the bug >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=346236#c74>. >>>>>>>>>>> It seems like there's a hope that some sites already have fallbacks >>>>>>>>>>> in >>>>>>>>>>> place to the standardized APIs, but it's not quite clear. Maybe you >>>>>>>>>>> could >>>>>>>>>>> try running a build of Chromium with the prefixed APIs disabled on >>>>>>>>>>> a random >>>>>>>>>>> sampling of the HTTP Archive sites, and reporting back on if the >>>>>>>>>>> user >>>>>>>>>>> experience changes or new errors show up in the JS console? That >>>>>>>>>>> could give >>>>>>>>>>> us more confidence in the removal. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There is an alternative set of APIs supported by all browsers >>>>>>>>>>>> that web authors can use. >>>>>>>>>>>> >>>>>>>>>>>> The full history of the removal attempt is here: crbug.com/ >>>>>>>>>>>> 346236 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Goals for experimentation >>>>>>>>>>>> >>>>>>>>>>>> The primary goal of the deprecation trial is to reduce the >>>>>>>>>>>> amount of broken user-visible experiences as the prefixed >>>>>>>>>>>> fullscreen APIs >>>>>>>>>>>> are removed, and to give time to web authors to transition to the >>>>>>>>>>>> modern >>>>>>>>>>>> API (which has been available for 5 years). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The un-prefixed fullscreen APIs have been available since >>>>>>>>>>>> Chrome M71. >>>>>>>>>>>> >>>>>>>>>>>> Experiment timeline >>>>>>>>>>>> >>>>>>>>>>>> TBD, with a proposed 3 months duration >>>>>>>>>>>> >>>>>>>>>>>> Blink component >>>>>>>>>>>> >>>>>>>>>>>> Blink>Fullscreen >>>>>>>>>>>> Blink>Media>Video >>>>>>>>>>>> >>>>>>>>>>>> TAG review >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> TAG review status >>>>>>>>>>>> >>>>>>>>>>>> Not applicable >>>>>>>>>>>> >>>>>>>>>>>> Risks >>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>> >>>>>>>>>>>> Web Compatibility: >>>>>>>>>>>> >>>>>>>>>>>> Removing non-standard APIs should overall help web >>>>>>>>>>>> compatibility, and encourage web authors to use the unprefixed >>>>>>>>>>>> APIs. Some >>>>>>>>>>>> experiences might be broken by this change, thus justifying this >>>>>>>>>>>> deprecation trial. The API has been deprecated for a significant >>>>>>>>>>>> amount of >>>>>>>>>>>> time however, and usage has gone down. >>>>>>>>>>>> >>>>>>>>>>>> This would only be an issue for websites that *only* support >>>>>>>>>>>> the prefixed APIs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Interoperability: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> All browsers have shipped the new APIs, most of them using an >>>>>>>>>>>> unprefixed version (Safari on iOS being the only remaining >>>>>>>>>>>> prefixed-only >>>>>>>>>>>> API). See also >>>>>>>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Based on the WPT results >>>>>>>>>>> <https://wpt.fyi/results/fullscreen/api/historical.html?label=master&label=experimental&aligned&q=%2Ffullscreen%2Fapi%2Fhistorical.html>, >>>>>>>>>>> Gecko supports none of the prefixed APIs, and WebKit supports all >>>>>>>>>>> of them. >>>>>>>>>>> I think this is worth noting in the ChromeStatus entry. (Although >>>>>>>>>>> it's not >>>>>>>>>>> an official signal, so leave the dropdown at "No signals".) >>>>>>>>>>> >>>>>>>>>>> Given this, filing a standards-positions issue on WebKit to get >>>>>>>>>>> their take on the deprecation might be a good idea. Sometimes those >>>>>>>>>>> discussions end up going in surprising directions; see e.g. this >>>>>>>>>>> request >>>>>>>>>>> for a position on the deprecation of mutation events >>>>>>>>>>> <https://github.com/WebKit/standards-positions/issues/192>. >>>>>>>>>>> >>>>>>>>>>> (Gecko also has their own, smaller set of prefixed APIs. But >>>>>>>>>>> it's not as relevant to this intent about the webkit-prefixed ones.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gecko: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WebKit: >>>>>>>>>>>> >>>>>>>>>>>> Web developers: >>>>>>>>>>>> >>>>>>>>>>>> Other signals: >>>>>>>>>>>> >>>>>>>>>>>> Activation >>>>>>>>>>>> >>>>>>>>>>>> Impact on the Ads ecosystem: >>>>>>>>>>>> >>>>>>>>>>>> N/A >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WebView application risks >>>>>>>>>>>> >>>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>>> applications? >>>>>>>>>>>> >>>>>>>>>>>> Potentially. The deprecation trial should give a heads up and >>>>>>>>>>>> appropriate time for apps to switch over to the unprefixed APIs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ongoing technical constraints >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Debuggability >>>>>>>>>>>> >>>>>>>>>>>> N/A >>>>>>>>>>>> >>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>> >>>>>>>>>>>> Yes - the prefixed API will be removed across all platforms. >>>>>>>>>>>> >>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> Yes >>>>>>>>>>>> >>>>>>>>>>>> WPTs testing the prefixes are removed: >>>>>>>>>>>> https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html >>>>>>>>>>>> >>>>>>>>>>>> WPTs testing the new API: >>>>>>>>>>>> https://github.com/web-platform-tests/wpt/tree/master/fullscreen/api >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Flag name on chrome://flags >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> Finch feature name >>>>>>>>>>>> >>>>>>>>>>>> PrefixedVideoFullscreen >>>>>>>>>>>> >>>>>>>>>>>> Non-finch justification >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>> >>>>>>>>>>>> False >>>>>>>>>>>> >>>>>>>>>>>> Launch bug >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> Estimated milestones >>>>>>>>>>>> >>>>>>>>>>>> DevTrial on desktop >>>>>>>>>>>> >>>>>>>>>>>> 123 >>>>>>>>>>>> >>>>>>>>>>>> DevTrial on Android >>>>>>>>>>>> >>>>>>>>>>>> 123 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>> >>>>>>>>>>>> https://chromestatus.com/feature/5259513871466496 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYegLwv%3Dusdjp%3DPagZDVKJLhUJwn6kuYpwr1yXgFDE6ZFQ%40mail.gmail.com.
