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/CAM0wra8DPG_etbALQoR9g_Q%2B30CH89NK5ma6oZt0__qY8Pna-g%40mail.gmail.com.
