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-6X-3yXjfn-MLWFXPrze-R4qowfo_%3DAZqpcckJkyH-W55A%40mail.gmail.com.
