[blink-dev] Intent to ship: Dedicated workers as service worker clients

451 views
Skip to first unread message

Asami Doi

unread,
Apr 1, 2021, 1:44:59 PM4/1/21
to blin...@chromium.org

Contact emails

asam...@chromium.org


Explainer

None


Specification

https://w3c.github.io/ServiceWorker/#control-and-use-worker-client 

> When the fetch is routed through HTTP fetch, the worker client's active service worker is set to the result of the service worker registration matching.


For service worker registration matching:

https://w3c.github.io/ServiceWorker/#scope-match-algorithm 


Summary

This change will affect the 2 parts in the behavior of dedicated workers.


Previous behaviors:

1) dedicated workers were not exposed to service workers via the Clients API.

2) dedicated workers were treated as part of their owner document and controlled by the document's service worker regardless of the dedicated worker script URL


New behaviors by this change:

1) dedicated workers will be real service worker clients and they will be exposed via the Clients API.

`Clients.matchAll({‘type’: ‘worker’})` will include dedicated workers. The ‘type’ option is an opt-in option and `Clients.matchAll()` returns only window clients by default.

2) dedicated workers will be controlled by their own service worker matched with the dedicated worker script URL.


New behaviors are aligned with the spec. It is achieved by updating a request for the worker script loading from renderer-initiated to browser-initiated.


Blink component

Blink>Worker


TAG review

None - this has long been part of an established spec, and we are just changing Chromium to follow it 


TAG review status

Not applicable


Risks


Interoperability and Compatibility  


The first possible risk is that the service worker that controls a dedicated worker may change. In particular:

  • A dedicated worker was previously controlled by a service worker, and is now uncontrolled.

  • A dedicated worker was previously not controlled by a service worker, and is now controlled.

  • A dedicated worker was previously controlled by a service worker, and is now controlled by a different service worker.


The dedicated worker controlled by a service worker is determined based on the scope matching. Previously, if the document matched a service worker’s scope, their child dedicated workers were also controlled. Developers might need to update their service worker scope or dedicated worker’s script path.


The second possible risk is that the behavior in Client and Clients API will change. Shared Worker was already exposed as clients. The changes are specifically:

  • `Client` with “worker” client type will be exposed. (WPT, wpt.fyi)

  • Note: The page needs to set 'worker' or 'all' inside the ClientQueryOptions passed matchAll() for dedicated workers to be exposed. This matches the existing behavior for shared workers.   


WorkerControlledByServiceWorkerOutOfScope in UseCounter shows the percentage of sites (almost 1%) that currently have a  dedicated worker that is incorrectly controlled by a service worker according to the spec. However, this number includes service workers that don’t have a fetch event handler, which will not be broken by this change. We are planning to refine the UseCounter (CL).


Gecko: Positive. Shipped based on the result of WPTs (listed in the “Is this feature fully tested by web-platform-tests?” section)


WebKit: No signal. Not supported yet based on the result of WPTs. Sent "Request for position" to webki...@lists.webkit.org https://lists.webkit.org/pipermail/webkit-dev/ (the email is not listed yet but will appear)


Web developers: Mixed


Positive:


Negative: We know of at least one site (internal) that has an out-of-scope dedicated worker that they need to be controlled for offline support. To avoid breakage, they plan to change their worker script URL to align with this change, while they don't seem to view this change as benefiting them.


Is this feature fully tested by web-platform-tests?

Yes


Some test cases in the following tests will be fixed:


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=906991 


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6591543769038848

Thanks, Asami

Chris Harrelson

unread,
Apr 1, 2021, 3:46:03 PM4/1/21
to Asami Doi, blink-dev
Hi,

Comments inline.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BvVX0hXrgKy1BZ4E1u%2BQe1xZ8%3DG5AqAzRwNwj29mOR-dYJkNQ%40mail.gmail.com.

Chris Harrelson

unread,
Apr 1, 2021, 3:53:55 PM4/1/21
to Asami Doi, blink-dev
Oops, accidentally pressed the send button. Actual comments below.

1% is quite a lot. It sounds like you are planning to refine the UseCounter to more accurately count cases that might be broken by this change?
 

Gecko: Positive. Shipped based on the result of WPTs (listed in the “Is this feature fully tested by web-platform-tests?” section)


To confirm, are you saying Gecko already has this behavior? Could you double check with some local testing?

Ben Kelly

unread,
Apr 1, 2021, 4:08:56 PM4/1/21
to Chris Harrelson, as...@mozilla.com, Asami Doi, blink-dev
I can confirm it does as I did a lot of work to implement it there previously.  This is a feature that has been in the spec a long time and delivering on past agreements to align with it.  Some past discussion where I raised this interop issue while still at mozilla:


It's possible things have changed there since I left, but I don't think so on this topic.  +as...@mozilla.com in case I got anything wrong.
 

Ben Kelly

unread,
Apr 5, 2021, 10:43:53 AM4/5/21
to Asami Doi, Chris Harrelson, as...@mozilla.com, blink-dev
On Mon, Apr 5, 2021 at 1:35 AM Asami Doi <asam...@chromium.org> wrote:
> 1% is quite a lot. It sounds like you are planning to refine the UseCounter to more accurately count cases that might be broken by this change?

Yes, I'm adding the UseCounter, kWorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope. This measures the risk of site breakage by this change.
https://chromium-review.googlesource.com/c/chromium/src/+/2799115

Just to clarify, it narrows the upper bound on breakage, but still doesn't exactly measure real breakage.  For example, many sites will have empty fetch handlers or fetch handlers that don't try to offline worker scripts.

Chris Harrelson

unread,
Apr 5, 2021, 11:24:28 AM4/5/21
to Ben Kelly, Asami Doi, as...@mozilla.com, blink-dev
Hi,
On Mon, Apr 5, 2021 at 7:43 AM Ben Kelly <wande...@chromium.org> wrote:
On Mon, Apr 5, 2021 at 1:35 AM Asami Doi <asam...@chromium.org> wrote:
> 1% is quite a lot. It sounds like you are planning to refine the UseCounter to more accurately count cases that might be broken by this change?

Yes, I'm adding the UseCounter, kWorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope. This measures the risk of site breakage by this change.
https://chromium-review.googlesource.com/c/chromium/src/+/2799115

Just to clarify, it narrows the upper bound on breakage, but still doesn't exactly measure real breakage.  For example, many sites will have empty fetch handlers or fetch handlers that don't try to offline worker scripts.

But the new UseCounter will be an upper-bound, right? If it returns a low number then perhaps that's good enough to ship this change. And if not, an analysis of sites that might be broken would be needed.

It sounds like we should wait for this new UseCounter before deciding how to proceed. Asami or Ben, do you have any concerns with that course of action?

Ben Kelly

unread,
Apr 5, 2021, 11:39:30 AM4/5/21
to Chris Harrelson, Asami Doi, as...@mozilla.com, blink-dev
On Mon, Apr 5, 2021 at 11:24 AM Chris Harrelson <chri...@chromium.org> wrote:
Hi,
On Mon, Apr 5, 2021 at 7:43 AM Ben Kelly <wande...@chromium.org> wrote:
On Mon, Apr 5, 2021 at 1:35 AM Asami Doi <asam...@chromium.org> wrote:
> 1% is quite a lot. It sounds like you are planning to refine the UseCounter to more accurately count cases that might be broken by this change?

Yes, I'm adding the UseCounter, kWorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope. This measures the risk of site breakage by this change.
https://chromium-review.googlesource.com/c/chromium/src/+/2799115

Just to clarify, it narrows the upper bound on breakage, but still doesn't exactly measure real breakage.  For example, many sites will have empty fetch handlers or fetch handlers that don't try to offline worker scripts.

But the new UseCounter will be an upper-bound, right? If it returns a low number then perhaps that's good enough to ship this change. And if not, an analysis of sites that might be broken would be needed.

It sounds like we should wait for this new UseCounter before deciding how to proceed. Asami or Ben, do you have any concerns with that course of action?

Correct, an upper bound.  I also had an idea on how we could refine it further if necessary in crbug.com/906991#c89.

I think waiting for more data sounds reasonable.

Asami Doi

unread,
Apr 5, 2021, 1:26:00 PM4/5/21
to Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev
> 1% is quite a lot. It sounds like you are planning to refine the UseCounter to more accurately count cases that might be broken by this change?

Yes, I'm adding the UseCounter, kWorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope. This measures the risk of site breakage by this change.
https://chromium-review.googlesource.com/c/chromium/src/+/2799115
On Fri, Apr 2, 2021 at 5:08 AM Ben Kelly <wande...@chromium.org> wrote:

Asami Doi

unread,
Apr 9, 2021, 1:30:35 AM4/9/21
to Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev
The new UseCounter is listed in chromestatus: https://www.chromestatus.com/metrics/feature/popularity#WorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope
The usage is less than 0.000001%. I'll wait for 1 or 2 weeks to collect more data.

Asami Doi

unread,
Apr 23, 2021, 2:35:47 AM4/23/21
to Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev

Hello API Owners,


I’d like to ask API owners’ opinions with the current result of UseCounters.


This feature changes Service Worker scope matching for Dedicated Workers so some dedicated workers might be controlled (not be controlled) although they used not to be controlled (used to be controlled).


The first UseCounter, WorkerControlledByServiceWorkerOutOfScope, counts the number of dedicated workers that will not be controlled by a service worker after this feature. It’s not equal to the number of possible broken sites unless dedicated workers send a HTTP request and the request is intercepted by a service worker. So this result is a maximum possible effect.


The second UseCounter, WorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope, counts the number of dedicated workers that will not be controlled by a service worker with a fetch event handler. It’s not equal to the number of possible broken sites because it includes an empty fetch event handler which does nothing. So this result is still an upper bound.

Note: In theory, there may be cases where the behavior of DW + SW with no/empty fetch handler changes due to the other functions in SW (e.g. install, activation events...)


I tried to refine the second UseCounter to exclude the sites with an empty fetch event handler but the implementation will be complicated. I’d like to avoid implementing another UseCounter if it’s not necessary.

Daniel Bratell

unread,
Apr 23, 2021, 4:13:32 AM4/23/21
to Asami Doi, Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev

Those numbers are high and if they had represented broken sites it would of course not work, so next step is to dig deeper into what those numbers represent and what the effect will be for individual sites.

A common method is to locate a sample set of sites that trigger the use counter and check them out individually to get an idea whether 1% or 90% of affected sites will break. (UKM; HTTP Archive; GitHub; ...)

Another method is to make the counters better at detecting sites that will break (as you mentioned) and see if those end up at an acceptable level, but as you know, there is a lot of latency in that method.

I don't think there is a third method. Even "common sense" "it is all noise" requires someone to take a look at real sites to confirm it.

/Daniel

Matt Falkenhagen

unread,
Apr 26, 2021, 8:23:17 PM4/26/21
to Daniel Bratell, Asami Doi, Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev
2021年4月23日(金) 17:13 Daniel Bratell <brat...@gmail.com>:

Those numbers are high and if they had represented broken sites it would of course not work, so next step is to dig deeper into what those numbers represent and what the effect will be for individual sites.

A common method is to locate a sample set of sites that trigger the use counter and check them out individually to get an idea whether 1% or 90% of affected sites will break. (UKM; HTTP Archive; GitHub; ...)

Thanks Daniel.

chromestatus has a section for the "top URLs that use the feature" based on HTTP Archive but it looks not yet populated for these counters:

Do we need to do work on our end to add support or does it just take time to populate?

For the feature to be logged it requires a service worker to be registered already from a previous, so if HTTP Archive only tests the first load it might not catch the sites that use the feature. I wonder if that's happening here.
 

Daniel Bratell

unread,
Apr 28, 2021, 4:56:57 AM4/28/21
to Matt Falkenhagen, Asami Doi, Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev, Philip Jägenstedt


On 2021-04-27 02:22, Matt Falkenhagen wrote:
2021年4月23日(金) 17:13 Daniel Bratell <brat...@gmail.com>:

Those numbers are high and if they had represented broken sites it would of course not work, so next step is to dig deeper into what those numbers represent and what the effect will be for individual sites.

A common method is to locate a sample set of sites that trigger the use counter and check them out individually to get an idea whether 1% or 90% of affected sites will break. (UKM; HTTP Archive; GitHub; ...)

Thanks Daniel.

chromestatus has a section for the "top URLs that use the feature" based on HTTP Archive but it looks not yet populated for these counters:

Do we need to do work on our end to add support or does it just take time to populate?

For the feature to be logged it requires a service worker to be registered already from a previous, so if HTTP Archive only tests the first load it might not catch the sites that use the feature. I wonder if that's happening here.

I don't really knows how that feature works. I know Philip J has helped with analysing sites before so maybe he knows more ?

/Daniel

Yoav Weiss

unread,
May 5, 2021, 8:52:14 AM5/5/21
to blink-dev, Matt Falkenhagen, Asami Doi, Ben Kelly, Chris Harrelson, as...@mozilla.com, blink-dev, Daniel Bratell
On Tuesday, April 27, 2021 at 2:23:17 AM UTC+2 Matt Falkenhagen wrote:
2021年4月23日(金) 17:13 Daniel Bratell <brat...@gmail.com>:

Those numbers are high and if they had represented broken sites it would of course not work, so next step is to dig deeper into what those numbers represent and what the effect will be for individual sites.

A common method is to locate a sample set of sites that trigger the use counter and check them out individually to get an idea whether 1% or 90% of affected sites will break. (UKM; HTTP Archive; GitHub; ...)

Thanks Daniel.

chromestatus has a section for the "top URLs that use the feature" based on HTTP Archive but it looks not yet populated for these counters:

Do we need to do work on our end to add support or does it just take time to populate?

For the feature to be logged it requires a service worker to be registered already from a previous, so if HTTP Archive only tests the first load it might not catch the sites that use the feature. I wonder if that's happening here.

Makes sense that HA won't trigger the use counter then..

Might be worthwhile to add the feature to the AllowedUkmFeatures list, to get a better sense (even if Google-only) on usage.

 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Chris Harrelson

unread,
Jun 10, 2021, 3:09:51 PM6/10/21
to Yoav Weiss, blink-dev, Matt Falkenhagen, Asami Doi, Ben Kelly, as...@mozilla.com, Daniel Bratell
Hi, friendly ping from the API owners. Is there more data coming in yet about safety of shipping this change?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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.
--
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.

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

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/532aeeaa-891e-4caa-a09d-4dddcc18e7a3n%40chromium.org.

Ben Kelly

unread,
Jun 10, 2021, 3:28:56 PM6/10/21
to Chris Harrelson, Yoav Weiss, blink-dev, Matt Falkenhagen, Asami Doi, as...@mozilla.com, Daniel Bratell
Asami will have the latest info, but the most recent up-to-date use counter shows ~0.7%:


I believe we are analyzing UKM to try to understand how the change will impact sites.

Asami Doi

unread,
Jun 10, 2021, 10:22:39 PM6/10/21
to Ben Kelly, Chris Harrelson, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
I analysed UKM and here is the summary:

- 3 sites out of 10 sites: No effect
Using a blob URL worker records the UseCounter. For a blob URL worker, scope matching with a service worker is a little different. A blob URL inherits the controller of the creator document or worker and the inherited URL is used for scope matching.

- 5 sites out of 10 sites: Unknown
No dedicated worker exists in the target URL. It exists somewhere in the subdirectory but we don't know the place from UKM.

- 2 sites out of 10 sites: Unknown
The target URL redirects to a different site. It probably occurs based on GeoLocation.

Recording the UseCounter if the site uses a blob URL worker makes sense due to the different scope matching mechanism. It doesn't break the site.
I think using a blob URL worker is the main reason that the UseCounter is not low. I will refine the UseCounter to exclude a blob URL worker.

Chris Harrelson

unread,
Jun 16, 2021, 11:26:37 AM6/16/21
to Asami Doi, Ben Kelly, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
Thanks for this data. It sounds like you're willing to refine the UKMs and see the new number?

Hopefully there will soon be HTTPArchive data associated with the use counter that you can use to dig in further and test on sites. If you can show that only at most (say) 1 in 10 of the sites are affected, and/or the effects are very minor, I think that'd be enough to unblock shipping this change. You're also welcome to flip the feature on in Canary/Dev as a way to gather more information.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALzRO2Smft8euHv0e50ENNNW3SOPc8k6f2PwSVujRbn-bME%3Dww%40mail.gmail.com.

Asami Doi

unread,
Jun 30, 2021, 6:56:34 AM6/30/21
to Chris Harrelson, Ben Kelly, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
Hello API owners,

Here is the latest update for use counters of this feature.

I refined the use counter to exclude blob URL dedicated workers because I found they are always recorded and increase the number of the previous use counter (ControlledWorkerWillBeUncontrolled).
The previous use counter recorded the number of dedicated workers that will not be controlled by any service workers, which is judged by service worker scope matching, after the feature is enabled. But a blob URL dedicated worker is an exceptional case because it inherits the active service worker of its parent and the scope matching with blob://foo and service worker's scope always fail. So using a blob URL worker should not be recorded in the use counter.
The refined use counter (ControlledNonBlobURLWorkerWillBeUncontrolled) was landed on June 17.

The previous use counter also suggested the 10 highest population websites that record the use counter and I analyzed each of them. I confirmed that some of them are using a blob URL worker and the sites do not break.
(note for analysis) https://docs.google.com/document/d/11VHfAu3bhlSFVNQrpgHFUHylp2KbUnkyeGHvDRds5Sk/edit?usp=sharing 

Thank you,
Asami

I 

Chris Harrelson

unread,
Jun 30, 2021, 12:34:52 PM6/30/21
to Asami Doi, Ben Kelly, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
Hi Asami, a question below.

On Wed, Jun 30, 2021 at 3:56 AM Asami Doi <asam...@chromium.org> wrote:

The previous use counter also suggested the 10 highest population websites that record the use counter and I analyzed each of them. I confirmed that some of them are using a blob URL worker and the sites do not break.
(note for analysis) https://docs.google.com/document/d/11VHfAu3bhlSFVNQrpgHFUHylp2KbUnkyeGHvDRds5Sk/edit?usp=sharing 

Are you saying that the top 10 highest population sites affected by this Intent will not be broken? If so, that's a very good sign.

Ben Kelly

unread,
Jun 30, 2021, 1:20:36 PM6/30/21
to Chris Harrelson, Asami Doi, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
On Wed, Jun 30, 2021 at 12:34 PM Chris Harrelson <chri...@chromium.org> wrote:
Hi Asami, a question below.

On Wed, Jun 30, 2021 at 3:56 AM Asami Doi <asam...@chromium.org> wrote:

The previous use counter also suggested the 10 highest population websites that record the use counter and I analyzed each of them. I confirmed that some of them are using a blob URL worker and the sites do not break.
(note for analysis) https://docs.google.com/document/d/11VHfAu3bhlSFVNQrpgHFUHylp2KbUnkyeGHvDRds5Sk/edit?usp=sharing 

Are you saying that the top 10 highest population sites affected by this Intent will not be broken? If so, that's a very good sign.

I don't think we have answers for all of them yet, but we've reached out.  So far we have not found any that break.

Also, while we are still waiting for more data to come in, the new use counter that excludes blob URLs is quite low so far (~0.003%).

Chris Harrelson

unread,
Jul 1, 2021, 6:22:38 PM7/1/21
to Ben Kelly, Asami Doi, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
Hi,

The API owners met today and discussed this intent. Our current understanding is that the new use counter measures an upper bound on possibly-broken sites, as blob URLs are not broken as I understand it.

Therefore, since the new use counter is currently at 0.003%, we plan to LGTM if it doesn't increase substantially in the next two weeks.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMj6Fq0MxLMof6EuVHikXa362aoLdkgURAHiP5A7bdcUAA%40mail.gmail.com.

Ben Kelly

unread,
Jul 12, 2021, 4:30:11 PM7/12/21
to Chris Harrelson, Asami Doi, Yoav Weiss, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
I know we're not quite two weeks since the last post, but I was looking at the counter today and it's actually come down even further.  It's closer to ~0.002% now.

Yoav Weiss

unread,
Jul 13, 2021, 2:18:55 AM7/13/21
to Ben Kelly, Chris Harrelson, Asami Doi, blink-dev, Matt Falkenhagen, as...@mozilla.com, Daniel Bratell
LGTM1

Thanks for aligning with the spec, and for pushing on compat analysis and bringing the risk to an acceptable level.

Matt Falkenhagen

unread,
Jul 14, 2021, 7:22:52 PM7/14/21
to Chris Harrelson, Ben Kelly, Asami Doi, Yoav Weiss, blink-dev, as...@mozilla.com, Daniel Bratell
2021年7月2日(金) 7:22 Chris Harrelson <chri...@chromium.org>:
Hi,

The API owners met today and discussed this intent. Our current understanding is that the new use counter measures an upper bound on possibly-broken sites, as blob URLs are not broken as I understand it.

Thanks for discussing this. For full transparency, Asami and I wanted to explain a subtlety of the upper bound.


Summary: it's not a strict upper bound but it can be treated as one.


We started with the UseCounter called WorkerControlledByServiceWorkerOutOfScope. This measures the case where both of the following are true:

  1. before this feature, a dedicated worker (DW) is controlled by a service worker (SW)

  2. after this feature, DW is not controlled by SW.


This is a strict upper bound, and was roughly 1.38%.


But we realized that the only risk is for service workers that try to intercept requests, so we refined the use counter to WorkerControlledByServiceWorkerWithFetchEventHandlerOutOfScope. This measures the case where:

  1. the same cases as WorkerControlledByServiceWorkerOutOfScope are true, and

  2. SW has a FetchEvent handler.


This is still a strict upper bound, and was roughly 0.799%.


We later found that some sites are intentionally wanting the DW to be controlled by another service worker, SW2, when the feature is enabled. So we refined the use counter to exclude these cases with ControlledWorkerWillBeUncontrolled, which measures the case where:

  1. before this feature, a DW is controlled by service worker SW

  2. SW has a FetchEvent handler

  3. after this feature, DW is not controlled by any service worker


This is no longer strictly an upper bound because the other SW2 might not be intended, but at roughly  0.798% the delta from the previous one was negligible. Therefore we believe this can still be considered an upper bound.


We later realized that blob URL workers are not affected by the change, so we refined the use counter to exclude these cases with ControlledNonBlobUrlWorkerWillBeUncontrolled (0.003%):