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/CAPNB-6Xya90shL78gUyi7mSyfBJLWVpRnjg_pBGa1NJBvbLezw%40mail.gmail.com.
