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/CAOMQ%2Bw889%3DMJw2zna%3D7nRo7NAZXgHL4n8%2ByufEXj4VX214tzOQ%40mail.gmail.com.
