(LGTM2, actually, given Alex's previous LGTM1.) On Wed, Jul 16, 2025 at 11:02 AM Domenic Denicola <dome...@chromium.org> wrote:
> Thanks for the extra diligence here! Some of those numbers do seem a bit > surprising, but ServiceWorker.SharedWorker.ResourceFetch.FromBlob being > 100% false is the most important one, so this sounds safe to me. > > LGTM1. > > On Tue, Jul 15, 2025 at 1:42 PM Yoshisato Yanagisawa < > yyanagis...@google.com> wrote: > >> Just update on the histogram I have added several months ago. >> >> Upon 28 days of >> aggregation, ServiceWorker.SharedWorker.ResourceFetch.FromBlob was 100% >> false on desktop (Win, mac, Linux). >> ServiceWorker.SharedWorker.ResourceFetch.UseServiceWorker was 100% true >> on desktop except for mac, but false on mac looks negligibly small. >> The latter one is out of my intuition because it means that if the fetch >> API is used inside SharedWorker, it is always controlled by ServiceWorker. >> However, I could not find anything suspicious from the code, and it might >> be the valid result. >> Also, ServiceWorker.GetClient.SharedWorkerScript.IsBlob >> and ServiceWorker.AddNonWindowClient.SharedWorkerScript.IsBlob are 100% >> false, and it is unlikely to look up blob URL >> SharedWorker with clients.match() or clients.matchAll(). >> >> Therefore, making blob URL SharedWorker aligned with the spec should not >> bring visible effect to web developers. >> >> What do you think? >> >> 2025年4月23日(水) 20:50 Yoav Weiss (@Shopify) <yoavwe...@chromium.org>: >> >>> That's great! Please let us know when data starts coming in :) >>> >>> On Thursday, April 17, 2025 at 5:53:15 AM UTC+2 Yoshisato Yanagisawa >>> wrote: >>> >>>> FYI, but the metric CL to count SW-controlled resource fetch from blob >>>> URL SharedWorker has been merged. >>>> https://chromium-review.googlesource.com/c/chromium/src/+/6458031 >>>> >>>> >>>> 2025年4月15日(火) 16:50 Yoshisato Yanagisawa <yyanagis...@google.com>: >>>> >>>>> I should say that one of the proposed metrics is too cumbersome to >>>>> plumb, and not implemented yet. However, to replay the LGTM, I prioritize >>>>> its implementation. >>>>> >>>>> 2025年4月15日(火) 3:08 Alex Russell <slightly...@chromium.org>: >>>>> >>>>>> Assuming these proposed metrics land in time to ship, LGTM1 >>>>>> >>>>>> On Wednesday, March 12, 2025 at 8:12:47 AM UTC-7 Mike Taylor wrote: >>>>>> >>>>>>> These proposed metrics sound reasonable to us, so long as they >>>>>>> capture all cases where the behavior is changing. But we defer to you >>>>>>> and >>>>>>> your team as the experts. >>>>>>> On 3/11/25 3:08 AM, 'Yoshisato Yanagisawa' via blink-dev wrote: >>>>>>> >>>>>>> The UMA and use count is recorded in the following code: >>>>>>> >>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:content/browser/service_worker/service_worker_main_resource_loader_interceptor.cc;l=132;drc=a5bdf0106da2489011a9846f280f29872258a8dd >>>>>>> >>>>>>> The usecount is set if the request URL is blob, and the navigation >>>>>>> handle has the service worker client and the client has a controller. >>>>>>> As >>>>>>> you can see, we record UMA just before the usecount, which records the >>>>>>> number of the blob URL and non-blob URL cases. Since we can see non >>>>>>> negligible IsBlob true cases, I assumed that the usecount is broken. >>>>>>> Note >>>>>>> that it just says that SharedWorker is created under a page controlled >>>>>>> by a >>>>>>> ServiceWorker. We are not sure if the change brings a visible >>>>>>> difference >>>>>>> to the SharedWorker. >>>>>>> >>>>>>> Considering what I have mentioned before, I should have added the >>>>>>> metrics like: >>>>>>> >>>>>>> - clients.matchAll() or match() look up the SharedWorker where >>>>>>> the SharedWorker script is a blob URL. >>>>>>> - SharedWorker fetches other resources while the SharedWorker >>>>>>> script is a blob URL. >>>>>>> >>>>>>> They should be the case affected by this change. Is there anything >>>>>>> else I missed? >>>>>>> >>>>>>> 2025年3月11日(火) 4:38 Chris Harrelson <chris...@chromium.org>: >>>>>>> >>>>>>>> Were you able to manually >>>>>>>> verify the SharedWorkerScriptUnderServiceWorkerControlIsBlob use >>>>>>>> counter >>>>>>>> hits with a test page? If so, I suppose it's possible no one is using >>>>>>>> this >>>>>>>> combination of features? Do you know of any site at all that does so? >>>>>>>> >>>>>>>> On Wed, Mar 5, 2025 at 5:32 PM 'Yoshisato Yanagisawa' via blink-dev >>>>>>>> <blink-dev@chromium.org> wrote: >>>>>>>> >>>>>>>>> Sorry for not working on this for a long time. >>>>>>>>> Considering what I am seeing with other statistics, I am assuming >>>>>>>>> the use count is wrong. >>>>>>>>> Last Dec, I started to do analysis on >>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5, >>>>>>>>> however it is really cumbersome to find a SharedWorker script in >>>>>>>>> obfuscated >>>>>>>>> JavaScript and the analysis did not go well. >>>>>>>>> As far as I understand, SharedWorker behavior change may happen: >>>>>>>>> 1. if SharedWorker `fetch()`, and the request is intercepted by >>>>>>>>> the ServiceWorker. >>>>>>>>> 2. or if the ServiceWorker tries to look up the SharedWorker as >>>>>>>>> its client, and postMessage(). >>>>>>>>> >>>>>>>>> I did not follow the 1 case, but as far as I checked 50 sites from >>>>>>>>> the beginning listed with >>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5, I >>>>>>>>> could not find the case like 2. >>>>>>>>> Therefore, I assume the risk is quite low. >>>>>>>>> >>>>>>>>> If the risk matters, I can also do the deprecation study. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2025年3月5日(水) 23:14 Daniel Bratell <bratel...@gmail.com>: >>>>>>>>> >>>>>>>>>> I assume it's this use counter: >>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5203 >>>>>>>>>> (SharedWorkerScriptUnderServiceWorkerControlIsBlob). It doesn't seem >>>>>>>>>> to >>>>>>>>>> have picked up any usage, which is either good or bad... >>>>>>>>>> >>>>>>>>>> yyanagisawa, do you know which it is? >>>>>>>>>> >>>>>>>>>> /Daniel >>>>>>>>>> On 2024-11-26 10:00, Domenic Denicola wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Nov 26, 2024 at 4:20 PM Yoshisato Yanagisawa < >>>>>>>>>> yyanagis...@google.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for the response, >>>>>>>>>>> Let me reply inline. >>>>>>>>>>> >>>>>>>>>>> 2024年11月19日(火) 15:56 Domenic Denicola <dome...@chromium.org>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 19, 2024 at 2:15 PM Yoshisato Yanagisawa < >>>>>>>>>>>> yyanagis...@google.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2024年11月18日(月) 17:02 Domenic Denicola <dome...@chromium.org>: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Friday, November 15, 2024 at 9:14:09 AM UTC+9 Chromestatus >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Contact emails yyanagis...@google.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> Explainer None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specification https://w3c.github.io/ >>>>>>>>>>>>>> ServiceWorker/#control-and-use-worker-client >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary >>>>>>>>>>>>>> >>>>>>>>>>>>>> According to https://w3c.github.io/ >>>>>>>>>>>>>> ServiceWorker/#control-and-use-worker-client, workers should >>>>>>>>>>>>>> inherit controllers for the blob URL. However, existing code >>>>>>>>>>>>>> allows only >>>>>>>>>>>>>> dedicated workers to inherit the controller, and shared workers >>>>>>>>>>>>>> do not >>>>>>>>>>>>>> inherit the controller. This is the fix to make Chromium >>>>>>>>>>>>>> behavior adjust to >>>>>>>>>>>>>> the specification. An enterprise policy >>>>>>>>>>>>>> SharedWorkerBlobURLFixEnabled is >>>>>>>>>>>>>> available to control this feature. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Blink component Blink>Workers >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWorkers> >>>>>>>>>>>>>> >>>>>>>>>>>>>> TAG review None >>>>>>>>>>>>>> >>>>>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>>>>> >>>>>>>>>>>>>> Risks >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a change to make the Chromium behavior aligned with >>>>>>>>>>>>>> the specification, there should not be an interoperability >>>>>>>>>>>>>> issue. However, >>>>>>>>>>>>>> there is a compatibility issue from the past Chromium. If a blob >>>>>>>>>>>>>> URL is >>>>>>>>>>>>>> used for a SharedWorker script and a controller for the URL is >>>>>>>>>>>>>> mattered, >>>>>>>>>>>>>> there is a behavior change because this change makes a controller >>>>>>>>>>>>>> inherited. An enterprise policy was added to allow enterprise >>>>>>>>>>>>>> customers to >>>>>>>>>>>>>> preserve the past Chromium behavior. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you have any metrics on how many page loads this change >>>>>>>>>>>>>> might impact? An enterprise policy seems like a good idea, but >>>>>>>>>>>>>> if the >>>>>>>>>>>>>> number of page loads is high, we might want to consider a >>>>>>>>>>>>>> deprecation trial >>>>>>>>>>>>>> or similar mechanism. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes. The I2S was proposed as the web facing change PSA ( >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/hClP93e4MLk/m/SGXfxOZfAQAJ) >>>>>>>>>>>>> before, and I gave up to go with the PSA due to the amount of the >>>>>>>>>>>>> case that >>>>>>>>>>>>> the blob URL is used as a SharedWorker script URL is too large. >>>>>>>>>>>>> I revisited the metrics and saw 10-40% SharedWorker script >>>>>>>>>>>>> URLs are blob URL depending on platform. >>>>>>>>>>>>> Is it better to go with a deprecation trial? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 10-40% is very high, so yes, we need to consider ways to find >>>>>>>>>>>> an upper limit on the danger. >>>>>>>>>>>> >>>>>>>>>>>> My guess is that most pages will not have their behavior >>>>>>>>>>>> changed, because, for example, their service worker JavaScript >>>>>>>>>>>> ignores >>>>>>>>>>>> non-https: fetches. The fact that these pages probably work fine >>>>>>>>>>>> in Safari >>>>>>>>>>>> is also helpful evidence. >>>>>>>>>>>> >>>>>>>>>>>> I would suggest two strategies: >>>>>>>>>>>> >>>>>>>>>>>> - Use UKM or HTTP Archive to examine the top-N sites that >>>>>>>>>>>> trigger this UseCounter (maybe N = 20 or so is good). Confirm >>>>>>>>>>>> via code >>>>>>>>>>>> inspection or running with the flag flipped or similar >>>>>>>>>>>> techniques that >>>>>>>>>>>> there is no compat impact. Publish this data for the API owners >>>>>>>>>>>> to see. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Sure. >>>>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/6049677 >>>>>>>>>>> to add UKM and UseCounter. >>>>>>>>>>> Let's see the statistics after it is shipped. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Oh, my suggestion was to get data sooner, by using the existing >>>>>>>>>> use counter with HTTP archive analysis >>>>>>>>>> <https://www.chromium.org/blink/platform-predictability/compat-tools/>. >>>>>>>>>> Then you don't have to wait for any code to roll out to stable. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> - Also do a deprecation trial to allow opting in to the old >>>>>>>>>>>> behavior. The UKM/HTTP archive analysis can increase our >>>>>>>>>>>> confidence that >>>>>>>>>>>> the breakage is low (like, if 0 or 1 out of 20 pages are >>>>>>>>>>>> broken, then the >>>>>>>>>>>> breakage is probably <1%). But it cannot give us enough >>>>>>>>>>>> precision to be >>>>>>>>>>>> confident, so having the escape hatch of the deprecation trial >>>>>>>>>>>> seems >>>>>>>>>>>> important. >>>>>>>>>>>> >>>>>>>>>>>> Just let me confirm if my understanding is correct. >>>>>>>>>>> Does the deprecation trial mean the origin trial to preserve the >>>>>>>>>>> legacy behavior? >>>>>>>>>>> We enable the flag by default while starting the origin trial. >>>>>>>>>>> The site with the origin trial token can preserve the legacy >>>>>>>>>>> behavior, >>>>>>>>>>> right? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, that's the idea! See this link >>>>>>>>>> <https://www.chromium.org/blink/launching-features/#deprecation-trial>. >>>>>>>>>> I guess the wording there is a bit confusing since you aren't >>>>>>>>>> "removing" a >>>>>>>>>> feature, but instead changing how an existing feature works. I think >>>>>>>>>> it >>>>>>>>>> should not matter much though. It is still closer to a deprecation >>>>>>>>>> trial >>>>>>>>>> than an origin trial. For example, you do not need to write a >>>>>>>>>> specification >>>>>>>>>> for the behavior that the trial enables, like you would with an >>>>>>>>>> origin >>>>>>>>>> trial. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm sorry that this adds so much process for what is basically >>>>>>>>>>>> a bug fix. It is possible there would be other ways to avoid it, >>>>>>>>>>>> for >>>>>>>>>>>> example by creating a more precise use counter that detects >>>>>>>>>>>> "changed >>>>>>>>>>>> behavior". (But, it is hard to imagine how to write the code for >>>>>>>>>>>> such a use >>>>>>>>>>>> counter... maybe something about comparing response bytes??) >>>>>>>>>>>> However my >>>>>>>>>>>> guess is that the time and effort of writing that precise use >>>>>>>>>>>> counter is >>>>>>>>>>>> probably more than the effort in setting up a deprecation trial. >>>>>>>>>>>> So my >>>>>>>>>>>> advice is to pursue the above approach. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Gecko*: No signal >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you ask Gecko for signals? I am especially curious why >>>>>>>>>>>>>> they haven't updated to match the specification. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sure. I have filed the mozilla's standard position for it. >>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/1113 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *WebKit*: Shipped/Shipping >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>>> >>>>>>>>>>>>>> n/a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Security >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since this is adjusting Chromium behavior to specification, >>>>>>>>>>>>>> there should not be a security risk from a specification >>>>>>>>>>>>>> perspective. From >>>>>>>>>>>>>> the implementation perspective, this change simply inherits >>>>>>>>>>>>>> existing >>>>>>>>>>>>>> controller. There should not be any additional security risks >>>>>>>>>>>>>> with this >>>>>>>>>>>>>> change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since SharedWorker is not supported on Android yet, there is >>>>>>>>>>>>>> no risk on Android WebView. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>> >>>>>>>>>>>>>> n/a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>>>>>>> No >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since SharedWorker is not supported in Android yet, the >>>>>>>>>>>>>> feature also does not affect to Android. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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/service-workers/service- >>>>>>>>>>>>>> worker/local-url-inherit-controller.https.html Same-origin >>>>>>>>>>>>>> blob URL sharedworker should inherit service worker controller. >>>>>>>>>>>>>> Same-origin >>>>>>>>>>>>>> blob URL sharedworker should intercept fetch(). The tests ensure >>>>>>>>>>>>>> a >>>>>>>>>>>>>> ServiceWorkerController is inherited. Due to >>>>>>>>>>>>>> crbug.com/40364838, Chromium does not pass the former test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Flag name on about://flags None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Finch feature name SharedWorkerBlobURLFix >>>>>>>>>>>>>> >>>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tracking bug https://crbug.com/324939068 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Estimated milestones Shipping on desktop 133 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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). >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>> https://chromestatus.com/feature/5137897664806912?gate= >>>>>>>>>>>>>> 5147843735322624 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>>>>> To view this discussion visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9fn%2B7i8%3DOh72j43C7nVeG4%3D850zaqZShgiaAhhTVBCpA%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9fn%2B7i8%3DOh72j43C7nVeG4%3D850zaqZShgiaAhhTVBCpA%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 visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6XY_%3DTj%3DWyi%3Dhh%3D-wny5beHqNAT7G_ObTR4eof-duXNdQ%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6XY_%3DTj%3DWyi%3Dhh%3D-wny5beHqNAT7G_ObTR4eof-duXNdQ%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 visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6WLWGs7NLckDw5v7XMy1WX6BefKunvNJQJ0wskrGFs0iQ%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6WLWGs7NLckDw5v7XMy1WX6BefKunvNJQJ0wskrGFs0iQ%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-YxeEze3h-359mkpMbG8zzvAw6cQ%2Bpe0fb_hWgjAERQA%40mail.gmail.com.
