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/3e999171-4fbe-4feb-bbc5-596038eca769n%40chromium.org.
