Intent to Ship: SharedWorker script inherit controller for blob script URL

[Chromestatus]

Contact emails

yyana...@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

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.

Gecko: No signal

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?

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.

[Domenic Denicola]

On Friday, November 15, 2024 at 9:14:09 AM UTC+9 Chromestatus wrote:

Contact emails yyana...@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

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.

 

Gecko: No signal

Can you ask Gecko for signals? I am especially curious why they haven't updated to match the specification.

[Yoshisato Yanagisawa]

2024年11月18日(月) 17:02 Domenic Denicola <dom...@chromium.org>:

On Friday, November 15, 2024 at 9:14:09 AM UTC+9 Chromestatus wrote:

Contact emails yyana...@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

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?

 

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

[Domenic Denicola]

On Tue, Nov 19, 2024 at 2:15 PM Yoshisato Yanagisawa <yyana...@google.com> wrote:

2024年11月18日(月) 17:02 Domenic Denicola <dom...@chromium.org>:

On Friday, November 15, 2024 at 9:14:09 AM UTC+9 Chromestatus wrote:

Contact emails yyana...@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

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.
• 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.

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.

[Yoshisato Yanagisawa]

Thanks for the response,

Let me reply inline.

2024年11月19日(火) 15:56 Domenic Denicola <dom...@chromium.org>:

On Tue, Nov 19, 2024 at 2:15 PM Yoshisato Yanagisawa <yyana...@google.com> wrote:

2024年11月18日(月) 17:02 Domenic Denicola <dom...@chromium.org>:

On Friday, November 15, 2024 at 9:14:09 AM UTC+9 Chromestatus wrote:

Contact emails yyana...@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

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. 

• 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?

[Domenic Denicola]

Oh, my suggestion was to get data sooner, by using the existing use counter with HTTP archive analysis. 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. 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.

[Daniel Bratell]

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

--
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+...@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.

[Yoshisato Yanagisawa]

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 <brat...@gmail.com>:

[Chris Harrelson]

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?

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.

[Yoshisato Yanagisawa]

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 <chri...@chromium.org>:

[Mike Taylor]

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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6WLWGs7NLckDw5v7XMy1WX6BefKunvNJQJ0wskrGFs0iQ%40mail.gmail.com.