New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistencies due to when clients are created #870

Closed
jakearchibald opened this Issue Apr 6, 2016 · 50 comments

Comments

Projects
None yet
7 participants
@jakearchibald
Copy link
Collaborator

jakearchibald commented Apr 6, 2016

https://jakearchibald.github.io/isserviceworkerready/demos/clients-count/

  1. Visit the above
  2. Hit shift + refresh
  3. Hit refresh

Chrome says 1, Firefox says 0.

The Firefox behaviour seems right to me, but unless I'm reading it wrong, the spec isn't clear around this. This might be because of earlier confusion around when clients are created.

From https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents:

Set request's client to the source browsing context's active document's Window object's environment settings object

If I'm reading this correctly, the client is the window being navigated, not a new client ready for the new page.

From https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-fetch-request-algorithm 12.1:

If client is not a secure context, return null.

This seems to assume that the client is a new client ready for the new page, but doesn't this mean that SW will fail if you're navigating from an unrelated insecure page?

@jakearchibald jakearchibald added this to the Version 1 milestone Apr 6, 2016

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 6, 2016

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Apr 6, 2016

I think this is a Firefox bug and chrome is more correct.

The current spec says to control windows. And it says to associate the service worker with the window (i.e. control it) before firing the FetchEvent. So there should be an existing controlled client when a navigation FetchEvent is fired.

The problem in Firefox is that we control documents, not windows. The document does not exist before the navigation, so we don't have a controlling client yet. There is a bug open for this, but there was some discussion at the last f2f that we might want to change to controlling documents in the spec. So we have not moved on this.

https://bugzilla.mozilla.org/show_bug.cgi?id=1237498

In regards to this spec language:

If client is not a secure context, return null.

I think the spec is trying to check for a non-secure parent window. It probably needs to be re-worded since it should use the navigation URL security and parent window security to make this determination.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 6, 2016

We should talk about this at the f2f. I think the Firefox behaviour makes more sense, especially given what we do with fetchEvent.clientId.

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Apr 6, 2016

If we decide to keep the "client is Window" behavior currently in spec, then I think we could revisit providing a value in fetchEvent.clientId for navigations. My objections there were largely based on my misconception about clients being documents.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 10, 2016

This issue is very related to #811

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 11, 2016

F2F:

  • A reserved client is created for a navigation
  • fetchEvent.clientId - represents the client that initiated the request
  • fetchEvent.reservedClientId - represents the client that has been created for potentially-client-creating request, which may not be used in the event of a redirect, content-disposition, network error, or other response rejection
  • fetchEvent.targetClientId - the id of the client that the new client will replace if it's used
  • clients.matchAll() will not return reserved clients
  • clients.matchAll({ includeReserved: true }) will return reserved clients
  • Reserved clients will have url about:blank
  • Reserved clients will inherit visual properties from their target client (which may be a cross origin client, or new tab)
  • client.used will be false for reserved clients
  • clients.get will return a reserved client
  • postMessage on a reserved client will be buffered

Some of the naming is up for bikeshedding, specifically:

  • "reserved", in all the properties it's used
  • targetClientId or replacesClientId - intent is to know which client
  • client.used
@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 11, 2016

openedWindow.location.href = 'blah' - what client initiates this request? The openedWindow or the window which executed the code?

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 11, 2016

targetClientId will be the same as reservedClientId if the link is being opened in a new window.

For worker requests targetClientId will be the same as reservedClientId

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Apr 13, 2016

@jakearchibald Can we mark this one decided? I thought we decided it in the meeting.

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Apr 13, 2016

@mattto

This comment has been minimized.

Copy link
Member

mattto commented Apr 22, 2016

@mkruisselbrink

This comment has been minimized.

Copy link
Collaborator

mkruisselbrink commented Apr 22, 2016

Since we didn't explicitly discuss this, I wonder if what we came up with also sufficiently addresses worker clients. For workers their settings object (client?) is created before the worker is fetched, and that worker is then used as the client for the actual request to fetch the worker.

So would that be an exception to the fetchEvent.clientId represents the client that initiated the request rule? Or since it's not a navigation (but it is a new controlled client) would we only have a clientId and have both reservedClientId and targetClientId be null/undefined?

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 19, 2016

For workers their settings object (client?) is created before the worker is fetched, and that worker is then used as the client for the actual request to fetch the worker.

I think this is not true. The fetch in run a worker is invoked with outside settings which is the source client.

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 19, 2016

I outlined the redefinition of the service worker client concept: https://gist.github.com/jungkees/03d4473ae47bd222539ab9cf5c9afd31

Hooks to HTML's navigation and run a worker will be needed (with some changes to whatwg/html#322).

In the gist proposal, I suggested we have a single .potentialClientId (with its state defined) over having both .reservedClientId and .targetClientId.

Please take a look.

/cc @annevk @jakearchibald @slightlyoff @mkruisselbrink @wanderview @ehsan

@annevk

This comment has been minimized.

Copy link
Member

annevk commented May 19, 2016

I don't really understand the motivation. It says a service worker can outlive a client, and then it goes on about how a service worker exists before a client is created.

How does this work in browsers today?

Supposedly we always know when we are creating a new client, so we could generate an ID that we then later use once the client is created. Is that what you're trying to accomplish here?

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 19, 2016

so we could generate an ID that we then later use once the client is created.

This is what I suggested.

  1. Navigation is triggered.
  2. [Navigation] Invoke fetch.
  3. [Fetch] Invoke Handle Fetch.
  4. [Handle Fetch] Create (potential) target client information
  5. [Navigation] Create (target) Window/Document
  6. [Navigation] Set Window/Document's client information to the value created in 4.

In order to do that, the step 4 and 6 above should be added. And for this, I wanted to have some internal slots for id and active worker on a fetch algorithm instance or on a request.

How does this work in browsers today?

Blink creates some corresponding state (object) when fetch occurs, and the properties in that object are later associated with the the document/worker. So, largely the steps I suggest here is what the implementation does now.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented May 19, 2016

I think it would be better if we created the ID between step 1 and 2 and pass that along in the request. After all, navigate ends up creating the document which is presumably where this information is stored eventually.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented May 19, 2016

(And a similar setup for workers.)

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 19, 2016

it would be better if we created the ID between step 1 and 2 and pass that along in the request.

This sounds fine to me.

How about the matched active worker? Handle fetch should be the best place for this I think. Any better idea?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented May 19, 2016

That would mean it would have to somehow make its way back up the chain (e.g., by sticking on a response), which seems a little ugly. What is needed to determine the active worker?

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 19, 2016

Right. Determining the active worker is done in Handle Fetch step 12.3. That is, the fetch is for a non-subresource request and the scope of the request url matches one of the registrations.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented May 19, 2016

Okay, so the worry is about some kind of race condition if we match twice on the URL? I think you have mentioned that earlier.

The operations performed on client there don't make sense, right? Client doesn't exist yet for non-subresource requests.

I think here too it makes more sense if we end up dictating what service worker to use. Rather than letting "Handle Fetch" figure it out somehow and tell us about it later what it came up with.

It also seems plausible we might have more such cases in the future where you'd want to fetch something using a particular service worker.

One way to do this would be to change the "skip-service-worker flag" of request into a "service worker" setting. Which is one of "none", "client", or a service worker instance of sorts.

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented May 19, 2016

Note, we're unlikely to get any review here from google folks while google I/O is going on this week.

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 20, 2016

@annevk I'm looking at more of how the implementations currently work. Blink finds matched registration in navigation algorithm equivalent phase and get its active worker right before dispatching the fetch event (in handle fetch algorithm equivalent phase). Your suggestion seems okay to me now. Let me try to examine a bit more next week. @wanderview Google folks will be able to have a look by then. On the spec side, Anne and I can discuss, and on the API side, more discussion would be needed I guess.

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented May 26, 2016

I think we should rather set the matched service worker registration to a request rather than the active worker. The active worker can change (by waiting worker being promoted) between the step in navigation and the step later in Handle Fetch if the registration has had both the active worker and the waiting worker.

Also, in the same reason, the active worker that will be attached to the client (document or other worker) should be determined when the registration's active worker for the fetch event is determined (in Handle Fetch). So, it seems to me that the active worker should be passed back to the caller within a response. Or can we create some outer object in navigate that has the active worker slot and pass the reference to fetch/Handle Fetch and change its state in the Handle Fetch?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented May 26, 2016

That seems like an unfortunate setup since in general fetch doesn't need to know about this, only for navigation.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 20, 2016

Resolution:

  • Define a super class object that holds client's id and target client id
  • Subclass environment settings object from the super class object
  • Clients methods enumerate the super class objects
  • Use target browsing context information gotten from request to capture the UI states of the target clients which reserved client will inherit.

@jungkees jungkees added the decided label Sep 20, 2016

jungkees pushed a commit to jungkees/html that referenced this issue Sep 27, 2016

Jungkee Song
Improve navigate for service worker hooks
Before this patch, we didn't have a concept that holds information
referenced from a service worker during a navigation (more precisely
before the actual global object and its relevant environment settings
object for the resulting resource is created).

This patch defines "set up a reserved environment settings object"
that temporarily holds the reserved id, the origin, the creation URL
and the target browsing context information such that service workers'
FetchEvent hanlder can reference this client before it's actually
created.

The changes include:
 - Add "set up a reserved environment settings object"
 - Set request's reserved client such that fetch (and Handle Fetch)
 can use it
 - Add Window object's active worker internal slot
 - Add WorkerGlobalObject's active worker internal slot
 - Add "match service worker registration" logic to attach controller

Related issue: w3c/ServiceWorker#870
Call flow: w3c/ServiceWorker#870 (comment)
Expected behavior: w3c/ServiceWorker#870 (comment)
Related changes:
 - SW (WIP): w3c/ServiceWorker@df39d89
 - Fetch:

jungkees pushed a commit to jungkees/html that referenced this issue Sep 28, 2016

Jungkee Song
Improve navigate for service worker hooks
Before this patch, we didn't have a concept that holds reserved
client's information referenced from a service worker during a
navigation (more precisely before the actual global object and its
relevant environment settings object for the resulting resource is
created).

This patch defines an "environment" concept (a supertype object of an
environment settings object) that has its id, creation URL and target
browsing context such that service workers' FetchEvent hanlder can
reference this client information before the corresponding environmet
setings object is actually created.

The changes include:
 - Create an environment (a reserved client) during a navigation
 - Set request's reserved client id such that fetch (and Handle Fetch)
 can use it
 - Set request's target client id such that fetch (and Handle Fetch)
 can use it
 - Add Window object's active worker internal slot
 - Add WorkerGlobalObject's active worker internal slot
 - Add "match service worker registration" logic to attach controller

Related issue: w3c/ServiceWorker#870
Call flow: w3c/ServiceWorker#870 (comment)
Expected behavior: w3c/ServiceWorker#870 (comment)
Related changes:
 - SW (WIP): w3c/ServiceWorker@df39d89
 - Fetch: whatwg/fetch#383

jungkees pushed a commit to jungkees/fetch that referenced this issue Sep 28, 2016

Jungkee Song
Add request's reserved client id and target client id
This patch defines request's reserved client id and target client id
that are set to a reserved environment's id and the target browsing
context's active document's settings object's id respectively during a
navigation. The given values are primarily used to provide the
reserved client's id and target client's id to service workers' fetch
event handlers.

Related issue: w3c/ServiceWorker#870
Call flow: w3c/ServiceWorker#870 (comment)
Expected behavior: w3c/ServiceWorker#870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - SW (WIP): w3c/ServiceWorker@df39d89

jungkees pushed a commit that referenced this issue Oct 6, 2016

Jungkee Song
(WIP) Improve registration matching and exposing reserved/target client
This patch fixes the client matching flow and exposes reserved client
and target client information by adding necessary hooks to fetch and
HTML.

Related issue: #870
Call flow: #870 (comment)
Expected behavior: #870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - Fetch: whatwg/fetch#383

* Work on Handle Fetch is done. Work on the client API is in progress.

jungkees pushed a commit to jungkees/html that referenced this issue Oct 13, 2016

Jungkee Song
Improve navigate for service worker hooks
Before this patch, we didn't have a concept that holds reserved
client's information referenced from a service worker during a
navigation (more precisely before the actual global object and its
relevant environment settings object for the resulting resource is
created).

This patch defines an "environment" concept (a supertype object of an
environment settings object) that has its id, creation URL and target
browsing context such that service workers' FetchEvent hanlder can
reference this client information before the corresponding environmet
setings object is actually created.

The changes include:
 - Create an environment (a reserved client) during a navigation
 - Set request's reserved client id such that fetch (and Handle Fetch)
 can use it
 - Set request's target client id such that fetch (and Handle Fetch)
 can use it
 - Add Window object's active worker internal slot
 - Add WorkerGlobalObject's active worker internal slot
 - Add "match service worker registration" logic to attach controller

Related issue: w3c/ServiceWorker#870
Call flow: w3c/ServiceWorker#870 (comment)
Expected behavior: w3c/ServiceWorker#870 (comment)
Related changes:
 - SW (WIP): w3c/ServiceWorker@df39d89
 - Fetch: whatwg/fetch#383

jungkees pushed a commit that referenced this issue Oct 13, 2016

Jungkee Song
(WIP) Improve registration matching and exposing reserved/target client
This patch fixes the client matching flow and exposes reserved client
and target client information by adding necessary hooks to fetch and
HTML.

Related issue: #870
Call flow: #870 (comment)
Expected behavior: #870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - Fetch: whatwg/fetch#383

* Work on Handle Fetch is done. Work on the client API is in progress.

jungkees pushed a commit that referenced this issue Oct 13, 2016

Jungkee Song
(WIP) Improve registration matching and exposing reserved/target client
This patch fixes the client matching flow and exposes reserved client
and target client information by adding necessary hooks to fetch and
HTML.

Related issue: #870
Call flow: #870 (comment)
Expected behavior: #870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - Fetch: whatwg/fetch#383

* Work on Handle Fetch is done. Work on the client API is in progress.

jungkees pushed a commit to jungkees/fetch that referenced this issue Oct 14, 2016

Jungkee Song
Add request's reserved client id and target client id
This patch defines request's reserved client id and target client id
that are set to a reserved environment's id and the target browsing
context's active document's settings object's id respectively during a
navigation. The given values are primarily used to provide the
reserved client's id and target client's id to service workers' fetch
event handlers.

Related issue: w3c/ServiceWorker#870
Call flow: w3c/ServiceWorker#870 (comment)
Expected behavior: w3c/ServiceWorker#870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - SW (WIP): w3c/ServiceWorker@df39d89

jungkees pushed a commit that referenced this issue Oct 14, 2016

Jungkee Song
(WIP) Improve registration matching and exposing reserved/target client
This patch fixes the client matching flow and exposes reserved client
and target client information by adding necessary hooks to fetch and
HTML.

Related issue: #870
Call flow: #870 (comment)
Expected behavior: #870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - Fetch: whatwg/fetch#383

* Work on Handle Fetch is done. Work on the client API is in progress.

jungkees pushed a commit that referenced this issue Oct 14, 2016

Jungkee Song
(WIP) Improve registration matching and exposing reserved/target client
This patch fixes the client matching flow and exposes reserved client
and target client information by adding necessary hooks to fetch and
HTML.

Related issue: #870
Call flow: #870 (comment)
Expected behavior: #870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - Fetch: whatwg/fetch#383

* Work on Handle Fetch is done. Work on the client API is in progress.

annevk added a commit to whatwg/html that referenced this issue Oct 24, 2016

Improve navigate for service worker hooks
Before this patch, there has been no concept that holds reserved
client's information referenced from a service worker during a
navigation (more precisely before the actual global object and its
relevant environment settings object for the resulting resource is
created).

This patch defines an "environment" concept (a supertype object of an
environment settings object) that has an id, a creation URL, a target
browsing context, and an active service worker such that service
workers' FetchEvent handlers can reference this client information
before the corresponding environment settings object is actually
created.

The changes include:
 - Create an environment (a reserved client) during a navigation; for
 worker creation requests, create an environment settings object and
 set the fields correspondingly
 - Set request's reserved client to the created environment or
 environment settings object such that fetch (and Handle Fetch) can
 use it
 - Set request's target client id such that fetch (and Handle Fetch)
 can use it

Note: The reserved client's active service worker is set, if
available, during the fetch (in service worker's Handle Fetch
algorithm).

Related issue: w3c/ServiceWorker#870
Related change: whatwg/fetch#383

annevk added a commit to jungkees/fetch that referenced this issue Oct 24, 2016

Add request's reserved client id and target client id
This patch defines request's reserved client id and target client id
that are set to a reserved environment's id and the target browsing
context's active document's settings object's id respectively during a
navigation. The given values are primarily used to provide the
reserved client's id and target client's id to service workers' fetch
event handlers.

Related issue: w3c/ServiceWorker#870
Call flow: w3c/ServiceWorker#870 (comment)
Expected behavior: w3c/ServiceWorker#870 (comment)
Related changes:
 - HTML: whatwg/html#1776
 - SW (WIP): w3c/ServiceWorker@df39d89

annevk added a commit to whatwg/fetch that referenced this issue Oct 24, 2016

Add request's reserved client and target client id
This patch defines the request's reserved client and the target client
id. The reserved client of a request is set to an environment or an
environment settings object during a navigation or a worker creation
request, respectively. The target client id of a request is set to the
target browsing context's active document's environment settings
object's id during a navigation. The given values are primarily used
to provide the reserved client's id and target client's id to service
workers' fetch event handlers.

This removes the request's target browsing context as the reserved
client provides the same information.

Related issue: w3c/ServiceWorker#870
Related change: whatwg/html#1776

dontcallmedom added a commit to dontcallmedom/fetch that referenced this issue Oct 24, 2016

Add request's reserved client and target client id
This patch defines the request's reserved client and the target client
id. The reserved client of a request is set to an environment or an
environment settings object during a navigation or a worker creation
request, respectively. The target client id of a request is set to the
target browsing context's active document's environment settings
object's id during a navigation. The given values are primarily used
to provide the reserved client's id and target client's id to service
workers' fetch event handlers.

This removes the request's target browsing context as the reserved
client provides the same information.

Related issue: w3c/ServiceWorker#870
Related change: whatwg/html#1776

dontcallmedom added a commit to dontcallmedom/fetch that referenced this issue Oct 24, 2016

Add request's reserved client and target client id
This patch defines the request's reserved client and the target client
id. The reserved client of a request is set to an environment or an
environment settings object during a navigation or a worker creation
request, respectively. The target client id of a request is set to the
target browsing context's active document's environment settings
object's id during a navigation. The given values are primarily used
to provide the reserved client's id and target client's id to service
workers' fetch event handlers.

This removes the request's target browsing context as the reserved
client provides the same information.

Related issue: w3c/ServiceWorker#870
Related change: whatwg/html#1776
@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Oct 25, 2016

Status note:

  • Addressed the following (8b483b0):
    • Use of request's reserved client (an environment or an environment settings object created during a navigation or a worker creation respectively in HTML) and request's target client id to expose fetchEvent.reservedClientId/targetClientId to fetch event handlers
    • Match a service worker registration and attach its active worker, if available, to the reserved client
  • Updated clients.get(id): 4ce01b5
  • Updated clients.matchAll(options): 3893c35
  • Updated clients.claim(): a279060
  • Added client.reserved: d88e979 - Defining the execution ready flag in HTML which .reserved uses is being tracked in whatwg/html#2004
@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Nov 4, 2016

The issue has been addressed by adding/modifying the relevant concepts and steps in SW, HTML (navigate, run a worker, etc.), and Fetch. (See #870 (comment) for the related changes.)

Closing.

@jungkees jungkees closed this Nov 4, 2016

blickly added a commit to google/closure-compiler that referenced this issue Aug 8, 2017

Correct typing of the FetchEvent.preloadResponse property a little.
The spec calls out some cases where this can resolve to undefined, such as
navigation preload not being turned on. See the cases where preloadResponse
resolves to undefined in this algorithm:
https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm

Also add targetClientId and reservedClientId to the spec from
w3c/ServiceWorker#870

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164604919

blickly added a commit to google/closure-compiler that referenced this issue Aug 8, 2017

Automated g4 rollback of changelist 164604919.
*** Reason for rollback ***

Breakages.

*** Original change description ***

Correct typing of the FetchEvent.preloadResponse property a little.

The spec calls out some cases where this can resolve to undefined, such as
navigation preload not being turned on. See the cases where preloadResponse
resolves to undefined in this algorithm:
https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm

Also add targetClientId and reservedClientId to the spec from
w3c/ServiceWorker#870

***

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164614311

blickly added a commit to google/closure-compiler that referenced this issue Aug 11, 2017

Add the PerformanceObserver API into closure externs.
Based on
https://w3c.github.io/performance-timeline/#dom-performanceobservercallback

Also add targetClientId and reservedClientId to the spec from
w3c/ServiceWorker#870

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164927249

alice added a commit to alice/html that referenced this issue Jan 8, 2019

Improve navigate for service worker hooks
Before this patch, there has been no concept that holds reserved
client's information referenced from a service worker during a
navigation (more precisely before the actual global object and its
relevant environment settings object for the resulting resource is
created).

This patch defines an "environment" concept (a supertype object of an
environment settings object) that has an id, a creation URL, a target
browsing context, and an active service worker such that service
workers' FetchEvent handlers can reference this client information
before the corresponding environment settings object is actually
created.

The changes include:
 - Create an environment (a reserved client) during a navigation; for
 worker creation requests, create an environment settings object and
 set the fields correspondingly
 - Set request's reserved client to the created environment or
 environment settings object such that fetch (and Handle Fetch) can
 use it
 - Set request's target client id such that fetch (and Handle Fetch)
 can use it

Note: The reserved client's active service worker is set, if
available, during the fetch (in service worker's Handle Fetch
algorithm).

Related issue: w3c/ServiceWorker#870
Related change: whatwg/fetch#383
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment