A service worker client represents one of a window, a dedicated worker and a shared worker. But it outlives the lifetime of the actual global objects of those environments. Specifically, fetch events to a service worker need the potential client's information before the acutal global object and its environment settings object are created.
An environment settings object would still be the best fit for a service worker client as it's naturally one-to-one with the corresponding global object i.e. the client and has access to the states defined there.
Information needed for a potential client: the client's id (an opaque string) and the active worker (a matched service worker or null)
Fetch (either an algorithm instance or a given request) would be a good place to carry those potential client information as it naturally hooks the source client to the (potential) target client.
A fetch has an associated potential client id (an opaque string) and an associated potential active worker (a service worker or null).
Upon a navigation, the Handle Fetch algorithm will:
- Set fetchEvent's clientId to request's client's id (i.e source client's id)
- Set fetch's potential client id to an opaque string and fetchEvent's potentialClientId to the same value
- Set fetch's potential active worker to (matched) registration's active worker
In the post-step of fetch during the navigation algorithm:
- Set window (or document)'s id to fetch's potential client id
- Set window (or document)'s active worker to fetch's potential active worker
Add the algorithms to get the window (or document)'s id and the active worker to the environment settings object definition.
Upon a worker creation, the Handle Fetch algorithm will:
- Set fetchEvent's clientId to request's client's id (i.e source client's id)
- Set fetch's potential client id to an opaque string and fetchEvent's potentialClientId to the same value
- Set fetch's potential active worker to (matched) registration's active worker
In the post-step of fetch during the run a worker algorithm:
- Set worker global's id to fetch's potential client id
- Set worker global's active worker to fetch's potential active worker
Add the algorithms to get the worker's id and the active worker to the environment settings object definition.
On second thougt after the f2f, distinguishing the reserved client and the target client adds unnecesary complexity. At the time the potential client's information is created, there's not enough information whether the fetch will land on a target client finally. So, rather than having them both, I suggest we have only the potential client with its state defined:
- clients.matchAll and clients.get will return a potential client
- Potential clients' client.state is initially "reserved" and set to "active" when the actual global object is created
- Potential clients whose client.used is false will have url about:blank
- postMessage on a potential client will be buffered
- potential clients wind up having no global object will be ditched. (The client objects that have already gotten will have their state attribute set to "removed".)
For a subresource fetch, FetchEvent.potentialClientId is set to the same value as the clientId. That is, the source client is equivalent to the target client.