Re: [w3c/ServiceWorker] clarify when FetchEvent.clientId will or will not be set for navigations (#1267)

I agree the design decision depends on the use cases.

Just to clarify, the assumption I had is simply use the request's client for `clientId`. (Wasn't this the very reason why we added `resultingClientId`? Otherwise, we could use `clientId` for both subresource requests and non-subresource requests as @slightlyoff suggested.) For navigation requests, it should be the environment of the source browsing context's active document. For worker requests, it should be the environment where the Worker/SharedWorker constructors are called. So they can be retrieved from:

> If the navigation is initiated from a cross-origin Client

There should be a source browsing context for this type of navigation requests although the client API won't be able to get a client instance from the `clientId`.

> If there is no Client at all, like the user entering a URL in the tab and pressing enter.

The tab should have a `Window` and an environment at the event of pressing enter. But there's no definition what the source browsing context should be for this navigation request I guess. So, `clientId` should be the empty string unless we define what it should be otherwise.

> Same-origin client setting window.location

The responsible browsing context specified by the incumbent settings object.

> Same-origin client setting iframe.src

iframe element's node document's browsing context.

> Same-origin client calling window.open()

The responsible browsing context specified by entry settings object.

> Same-origin client calling clients.openWindow()

We should define this; it should be the newly created browsing context that the method navigate.

> Client calling new Worker()

The environment where the Worker constructor is called.

> Client calling new SharedWorker() where no one else is attached yet

The environment where the Worker constructor called.

For the other thoughts:

> Its just a bit non-ideal to try to use the same information for policy in one case, but exempt it from that policy in others. But maybe thats an implementation specific concern.

I think that's rather natural based on the distinction between subresource requests and non-subresource (main resource) requests?

> I kind of like the simplicity of clientId just being empty/null for all navigations.

If this is the case, dropping `resultingClientId` in favor of having `clientId` represent either a subresource request's client or a non-subresource request's client can be an option I guess.

> Do we know if people are really asking for a non-empty clientId for these cases?

This seems like the key for decision.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1267#issuecomment-362198012