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/ddcb8bce-7858-4246-9494-e8426f98ccb4n%40chromium.org.
