Note in case folks missed it, <usermedia> is pausing their launch and extending their OT <https://groups.google.com/a/chromium.org/g/blink-dev/c/RtvK2dTcrEI?e=48417069> instead in order to give more time to address some of the feedback.
On Tue, May 5, 2026 at 3:58 PM 'Thomas Nguyen' via blink-dev < [email protected]> wrote: > Thanks for the standards position requests. But they reference >> https://github.com/w3c/mediacapture-extensions/pull/168 which is more >> recent, has outstanding review comments, and looks quite different ( >> preview >> <https://pr-preview.s3.amazonaws.com/tungnh28/mediacapture-extensions/pull/168.html#media-capture-html-elements> >> , explainer >> <https://github.com/tungnh28/mediacapture-extensions/blob/5884ebfb706ff227da2429447470c53b11ec6fa0/media-capture-elements-explainer.md>) >> from spec references and explainers in this I2S. >> For clarity on how those requests relate to this I2S, what exactly is >> intended to ship? Will <usermedia> deviate from what's described in >> the standards position requests, and if so how? > > That’s a good catch. The explainer in > https://github.com/w3c/mediacapture-extensions/pull/168 is the most > accurate reflection of the plan (including both MVP for <usermedia> and > post-MVP <camera> and <microphone> shipping). I'll make sure the I2S > document is updated to point to that link as soon as it lands. > > The *"Goals for experimentation"* part that was removed mentioned: >> *"To ensure a seamless transition and prevent disruption for our valued >> OT partners, this trial will initially launch with an API shape that is >> functionally equivalent to the previous <permission> trial, simply using >> the new <usermedia> element name".*Does this also apply to what's >> shipping? A lot of the agreement that was reached over this API came from >> abandoning the request permission-ahead-of-use in favor of the established >> permission-at-point-of-use model on the web. >> Specifically, will the MVP <usermedia> element allow requesting >> permission ahead of turning on camera/microphone devices? If yes, do you >> have a migration path away from that model, as it is generally a regression >> of the web model that is web incompatible? > > You’re right, the original OT had a different scope. To address the > concerns in the MVP launch, we are implementing a migration path allowing > sites to opt into the new element at their own pace (while keeping the > behavior the same as the generic permission element), and we are evaluating > a reverse OT to further assist this transition. > To ensure a smooth transition for developers, we have prepared a migration > document detailing the necessary steps. I'll update the doc as a public > link and share it here shortly. (or in the above PR). > > On Fri, May 1, 2026 at 8:08 PM Jan-Ivar Bruaroey <[email protected]> > wrote: > >> On Thursday, April 23, 2026 at 11:02:51 AM UTC-4 Minh Le wrote: >> >> Hi Dan, >> thank you for the reminder, here are the standard positions requests >> >> - https://github.com/WebKit/standards-positions/issues/651 >> - https://github.com/mozilla/standards-positions/issues/1392 >> >> >> Thanks for the standards position requests. But they reference >> https://github.com/w3c/mediacapture-extensions/pull/168 which is more >> recent, has outstanding review comments, and looks quite different ( >> preview >> <https://pr-preview.s3.amazonaws.com/tungnh28/mediacapture-extensions/pull/168.html#media-capture-html-elements>, >> explainer >> <https://github.com/tungnh28/mediacapture-extensions/blob/5884ebfb706ff227da2429447470c53b11ec6fa0/media-capture-elements-explainer.md>) >> from spec references and explainers in this I2S. >> >> For clarity on how those requests relate to this I2S, what exactly is >> intended to ship? Will <usermedia> deviate from what's described in >> the standards position requests, and if so how? >> >> The *"Goals for experimentation"* part that was removed mentioned: *"To >> ensure a seamless transition and prevent disruption for our valued OT >> partners, this trial will initially launch with an API shape that is >> functionally equivalent to the previous <permission> trial, simply using >> the new <usermedia> element name".* >> >> Does this also apply to what's shipping? A lot of the agreement that was >> reached over this API came from abandoning the request >> permission-ahead-of-use in favor of the established >> permission-at-point-of-use model on the web. >> >> Specifically, will the MVP <usermedia> element allow requesting >> permission ahead of turning on camera/microphone devices? If yes, do you >> have a migration path away from that model, as it is generally a regression >> of the web model that is web incompatible? >> >> On Wednesday, April 29, 2026 at 11:19:55 AM UTC-4 [email protected] >> wrote: >> >>> LGTM3 >>> >>> On Tuesday, April 28, 2026 at 11:23:38 AM UTC-7 [email protected] wrote: >>> >>>> Please update the chromestatus entry to specify the new TAG review for >>>>> <usermedia> rather than the old PEPC one, and link to the new webkit >>>>> standards position. >>>> >>>> Done, thanks. >>>> >>>> Also, this I2S specifies "goals for experimentation" - why is that >>>>> there? You're asking to fully ship, right? >>>> >>>> I think that's a left over we filled in in the OT request. Removed that. >>>> >>>> On Tue, Apr 28, 2026 at 5:55 PM Chris Harrelson <[email protected]> >>>> wrote: >>>> >>> Please update the chromestatus entry to specify the new TAG review for >>>>> <usermedia> rather than the old PEPC one, and link to the new webkit >>>>> standards position. >>>>> >>>>> Also, this I2S specifies "goals for experimentation" - why is that >>>>> there? You're asking to fully ship, right? >>>>> >>>>> On Mon, Apr 27, 2026 at 2:51 AM 'Thomas Nguyen' via blink-dev < >>>>> [email protected]> wrote: >>>>> >>>> That sounds like a solid idea. Thank you for the suggestion, Philipp; I >>>>>> have noted it down. >>>>>> We will certainly add this to our roadmap and include the sample >>>>>> after the API is merged into the media capture extensions. This will >>>>>> ensure >>>>>> better alignment with the approved shape. >>>>>> >>>>>> >>>>>> On Sat, Apr 25, 2026 at 4:57 PM Philipp Hancke < >>>>>> [email protected]> wrote: >>>>>> >>>>> Looking forward to this shipping! Can you please also add a sample to >>>>>>> https://github.com/webrtc/samples >>>>>>> which remains a go-to location for all things getUserMedia and >>>>>>> WebRTC (maybe we can get it to 15k stars finally ;-)) >>>>>>> >>>>>>> Am Mi., 15. Apr. 2026 um 16:39 Uhr schrieb Chromestatus < >>>>>>> [email protected]>: >>>>>>> >>>>>> *Contact emails* >>>>>>>> [email protected], [email protected] >>>>>>>> >>>>>>>> *Explainer* >>>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>>>>>> >>>>>>>> *Specification* >>>>>>>> https://wicg.github.io/PEPC/permission-elements.html >>>>>>>> >>>>>>>> *Summary* >>>>>>>> Usermedia Capability Element, is a declarative, user-activated >>>>>>>> control for accessing the starting and interacting with media streams. >>>>>>>> This >>>>>>>> addresses the long-standing problem of permission prompts being >>>>>>>> triggered >>>>>>>> directly from JavaScript without a strong signal of user intent. By >>>>>>>> embedding a browser-controlled element in the page, the user's click >>>>>>>> provides a clear, intentional signal. This enables a much better >>>>>>>> prompt UX >>>>>>>> and, crucially, provides a simple recovery path for users who have >>>>>>>> previously denied the permission. Note: This feature was previously >>>>>>>> developed and tested in an Origin Trial as the more generic >>>>>>>> <permission> >>>>>>>> element. Based on feedback from developers and other browser vendors, >>>>>>>> it >>>>>>>> has evolved into capability-specific elements to provide a more >>>>>>>> tailored >>>>>>>> and powerful developer experience. >>>>>>>> >>>>>>>> *Blink component* >>>>>>>> Public Trackers > Chromium Public Trackers > Chromium > Internals > >>>>>>>> Permissions > PermissionElement >>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Public%20Trackers%20%3E%20Chromium%20Public%20Trackers%20%3E%20Chromium%20%3E%20Internals%20%3E%20Permissions%20%3E%20PermissionElement%22> >>>>>>>> >>>>>>>> *Web Feature ID* >>>>>>>> permissions <https://webstatus.dev/features/permissions> >>>>>>>> >>>>>>>> *Motivation* >>>>>>>> The current web permission model for interacting with user media >>>>>>>> relies on JavaScript-triggered prompts, giving the user agent no strong >>>>>>>> signal of user intent. This results in out-of-context prompts, user >>>>>>>> frustration, and difficult-to-recover-from denial states. We propose >>>>>>>> the >>>>>>>> <usermedia> element, or a suite of elements. This will be semantic HTML >>>>>>>> control with browser-controlled content and strict styling constraints. >>>>>>>> These constraints are fundamental to the security model, ensuring a >>>>>>>> very >>>>>>>> high level of confidence in the user's intent when making a permission >>>>>>>> decision at both the site and OS level. Crucially, the <usermedia> >>>>>>>> element >>>>>>>> evolves beyond simply managing permissions; it streamlines the entire >>>>>>>> journey by also facilitating starting and interacting with media >>>>>>>> streams. >>>>>>>> This often eliminates the need for separate JavaScript API calls, >>>>>>>> simplifying implementation and creating a more seamless user flow. By >>>>>>>> providing a clear, consistent, in-page control, this element solves >>>>>>>> significant user problems related to context blindness and "permission >>>>>>>> regret," offering a simple recovery path from a previously denied >>>>>>>> state. >>>>>>>> The combination of a user-initiated element and a subsequent >>>>>>>> browser-controlled confirmation UI enhances intent capture, improves >>>>>>>> accessibility, and prevents manipulative patterns, providing a >>>>>>>> significantly better experience for both users and developers. >>>>>>>> >>>>>>>> *Initial public proposal* >>>>>>>> https://github.com/WICG/PEPC/issues/62 >>>>>>>> >>>>>>>> *TAG review* >>>>>>>> https://github.com/w3ctag/design-reviews/issues/1079 >>>>>>>> >>>>>>>> *TAG review status* >>>>>>>> Issues addressed >>>>>>>> >>>>>>>> *Origin Trial Name* >>>>>>>> UserMediaElement >>>>>>>> >>>>>>>> *Goals for experimentation* >>>>>>>> This Origin Trial serves two primary purposes: ensuring continuity >>>>>>>> for existing partners who have successfully integrated this pattern, >>>>>>>> and >>>>>>>> providing a platform to validate and iterate on the new, >>>>>>>> capability-specific <usermedia> element. While our previous Origin >>>>>>>> Trial >>>>>>>> for <permission> provided strong evidence for the core user-initiated >>>>>>>> model, feedback from developers and browser vendors prompted us to >>>>>>>> evolve >>>>>>>> the design. This new trial is essential for gathering insights on a >>>>>>>> refined, data-centric API shape to help us reach cross-browser >>>>>>>> consensus. >>>>>>>> To ensure a seamless transition and prevent disruption for our valued >>>>>>>> OT >>>>>>>> partners, this trial will initially launch with an API shape that is >>>>>>>> functionally equivalent to the previous <permission> trial, simply >>>>>>>> using >>>>>>>> the new <usermedia> element name. This provides a stable foundation >>>>>>>> from >>>>>>>> which we will iterate based on further discussion. Our goal is to >>>>>>>> evolve >>>>>>>> this element towards our proposed data-centric design ( >>>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md). >>>>>>>> However, we recognize that this more advanced API has raised >>>>>>>> compatibility >>>>>>>> and complexity concerns with developers ( >>>>>>>> https://github.com/WICG/PEPC/issues/62). Therefore, a primary >>>>>>>> objective of this trial is to work closely with the community to >>>>>>>> address >>>>>>>> these concerns and refine the final API. TPAC WebRTC minutes >>>>>>>> https://www.w3.org/2025/11/11-webrtc-minutes.html#551 >>>>>>>> >>>>>>>> *Chromium Trial Name* >>>>>>>> UserMediaElement >>>>>>>> >>>>>>>> *Origin Trial documentation link* >>>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>>>>>> >>>>>>>> *WebFeature UseCounter name* >>>>>>>> kHTMLPermissionElement >>>>>>>> >>>>>>>> *Risks* >>>>>>>> >>>>>>>> >>>>>>>> *Interoperability and Compatibility* >>>>>>>> There is a risk that this feature fails to be adopted by other >>>>>>>> browsers. This can be mitigated by backwards designing a reasonable >>>>>>>> fallback mechanism so that the element can degrade gracefully if the >>>>>>>> it's >>>>>>>> in an unsupported environment. >>>>>>>> >>>>>>>> *Gecko*: Under consideration ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/1245) >>>>>>>> >>>>>>>> *WebKit*: No signal >>>>>>>> >>>>>>>> *Web developers*: Positive >>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393820279 >>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393861768 >>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393911331 >>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2619657041 >>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482975001 >>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482981942 >>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3498355775 >>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3513734884 >>>>>>>> >>>>>>>> *Other signals*: >>>>>>>> >>>>>>>> *Ergonomics* >>>>>>>> No foreseen ergonomics risks. >>>>>>>> >>>>>>>> *Activation* >>>>>>>> A polyfill can help developers use this feature without risking >>>>>>>> broken functionality on non-supporting browsers. >>>>>>>> >>>>>>>> *Security* >>>>>>>> https://github.com/WICG/PEPC/blob/main/explainer.md#Security >>>>>>>> >>>>>>>> *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? >>>>>>>> Feature is not shipping on WebView due to it requiring permission >>>>>>>> manager embedder support. >>>>>>>> >>>>>>>> >>>>>>>> *Debuggability* >>>>>>>> The element raises issues to the devtools issues panel which help >>>>>>>> developers debug issues with their usage of the element. >>>>>>>> >>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>> No >>>>>>>> The element is not supported on Android WebView as it requires >>>>>>>> permission manager support to function and the WebView permission >>>>>>>> manager >>>>>>>> defers most permission decisions to the embedder by design. >>>>>>>> >>>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>>> Yes >>>>>>>> https://wpt.fyi/results/html/semantics/permission-element/usermedia >>>>>>>> >>>>>>>> *DevTrial instructions* >>>>>>>> https://github.com/WICG/PEPC/blob/main/HOWTO.md#enabling-usermedia >>>>>>>> >>>>>>>> *Flag name on about://flags* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Finch feature name* >>>>>>>> UserMediaElement >>>>>>>> >>>>>>>> *Rollout plan* >>>>>>>> Will ship enabled for all users >>>>>>>> >>>>>>>> *Requires code in //chrome?* >>>>>>>> True >>>>>>>> >>>>>>>> *Tracking bug* >>>>>>>> https://crbug.com/443013457 >>>>>>>> >>>>>>>> *Availability expectation* >>>>>>>> Feature is available only in Chromium browsers. We are not aware of >>>>>>>> other browsers adoption. >>>>>>>> >>>>>>>> *Adoption expectation* >>>>>>>> Feature is used by specific partner(s) to provide functionality >>>>>>>> within 12 months of launch in Chrome. Partners who are tested the >>>>>>>> feature >>>>>>>> in OT are expected to continue usage. >>>>>>>> >>>>>>>> *Adoption plan* >>>>>>>> We are planning to publish on developer.chrome.com and do further >>>>>>>> partner outreach >>>>>>>> >>>>>>>> *Non-OSS dependencies* >>>>>>>> >>>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>>> open source repository and its open-source dependencies to function? >>>>>>>> No >>>>>>>> >>>>>>>> *Estimated milestones* >>>>>>>> Shipping on desktop 149 >>>>>>>> Origin trial desktop first 144 >>>>>>>> Origin trial desktop last 148 >>>>>>>> DevTrial on desktop 144 >>>>>>>> Shipping on Android 149 >>>>>>>> Origin trial Android first 144 >>>>>>>> Origin trial Android last 148 >>>>>>>> DevTrial on Android 144 >>>>>>>> >>>>>>>> *Anticipated spec changes* >>>>>>>> >>>>>>>> Open questions about a feature may be a source of future web compat >>>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>>> issues in the project for the feature specification) whose resolution >>>>>>>> may >>>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>>> structure of >>>>>>>> the API in a non-backward-compatible way). >>>>>>>> This is an MVP launch. The MVP feature is fully functional and used >>>>>>>> by developers right now. We are working closely with the WebRTC on >>>>>>>> post-MVP >>>>>>>> features, the open topics will based on the foundation of the MVP, >>>>>>>> that we >>>>>>>> agreed upon with the WebRTC. Some of the open topics are for example: >>>>>>>> In >>>>>>>> the future, we might want to add a parameter to the getUserMedia >>>>>>>> algorithm >>>>>>>> so that the algorithm can determine whether the getUserMedia is called >>>>>>>> from >>>>>>>> the <usermedia> element or getUserMedia API. Potential to add >>>>>>>> additional >>>>>>>> attributes for <usermedia> interface. We're putting finishing touches >>>>>>>> on >>>>>>>> the spec now, work-in-progress PR is here, but once that lands we want >>>>>>>> to >>>>>>>> ship for M149 so wanted to start the discussion now. >>>>>>>> >>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>> >>>>>>>> https://chromestatus.com/feature/4926233538330624?gate=6467532078841856 >>>>>>>> >>>>>>>> *Links to previous Intent discussions* >>>>>>>> Intent to Prototype: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.com >>>>>>>> Intent to Experiment: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6942ed09.050a0220.1050d6.0961.GAE%40google.com >>>>>>>> >>>>>>>> >>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>> <https://chromestatus.com>. >>>>>>>> >>>>>>>> -- >>>>>>>> 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/69dfa184.050a0220.c8e20.03e8.GAE%40google.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thomas Nguyen >>>>>> >>>>>> Software Engineer >>>>>> >>>>>> [email protected] >>>>>> >>>>>> Google Germany GmbH >>>>>> >>>>>> Erika-Mann-Straße 33 >>>>>> >>>>>> 80636 München >>>>>> >>>>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>>>> >>>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>>> >>>>>> Sitz der Gesellschaft: Hamburg >>>>>> >>>>>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise >>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>>> bitte >>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>>>> >>>>>> >>>>>> >>>>>> This e-mail is confidential. If you received this communication by >>>>>> mistake, please don't forward it to anyone else, please erase all copies >>>>>> and attachments, and please let me know that it has gone to the wrong >>>>>> person. >>>>>> >>>>>> -- >>>>>> 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/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>> >>>> -- >>>> >>>> Thomas Nguyen >>>> >>>> Software Engineer >>>> >>>> [email protected] >>>> >>>> Google Germany GmbH >>>> >>>> Erika-Mann-Straße 33 >>>> >>>> 80636 München >>>> >>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>> >>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>> >>>> Sitz der Gesellschaft: Hamburg >>>> >>>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise >>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte >>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>> >>>> >>>> >>>> This e-mail is confidential. If you received this communication by >>>> mistake, please don't forward it to anyone else, please erase all copies >>>> and attachments, and please let me know that it has gone to the wrong >>>> person. >>>> >>> > > -- > > Thomas Nguyen > > Software Engineer > > [email protected] > > Google Germany GmbH > > Erika-Mann-Straße 33 > > 80636 München > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > > -- > 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/CA%2BoJCSwo%3Du6bGD5C7M0bnr1mNbnregxxx8gsLzaTUEFpc0_bEQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BoJCSwo%3Du6bGD5C7M0bnr1mNbnregxxx8gsLzaTUEFpc0_bEQ%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-R150t8n8p7qvoZ3Ju1KuKguhNazFeqg20rtYHObnn5A%40mail.gmail.com.
