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-6X1idth1y2NQsd6m1eN8%2ByQ--mVgUr%2Bq9o0hUx2cVM4oA%40mail.gmail.com.
