Re: [ServiceWorker] What is FetchEvent.clientId for navigation requests (#808)

I implemented FetchEvent.clientId based on the previous text of the spec, and I think the implementation is pretty straightforward.  Here is what I understood from the previous text of the spec:

FetchEvent.clientId should be set to the ID corresponding to the client that the document being navigated to represents.  In Gecko, the implementation works by computing a client ID on something close to our notion of clients settings object as the navigation is starting and passing that to the non-subresource FetchEvent that is going to be dispatched.  If the navigation finishes successfully, we use the computed client ID as the client ID for the respective client.

The reason why I disagree with this spec change is that if a developer actually needs the clientId for the top-level document, we're making them go through unnecessary hoops, since this change will force them to get the clientId out of a subsequent fetch and/or Clients.matchAll(), in both cases they'd have to solve the problem of how to verify the clientId that they get actually belongs to the document they have observed a FetchEvent for before.

A number of objections raised in the Mozilla bug and my response to them:

* What if the document doesn't get created, for example in the case of a network error?
** Then the client ID will never end up getting used, and doing things such as postMessage() to it won't work, exactly like a client ID belonging to a document that has been destroyed since the author obtained it.
* What if you clicked a link on a source document to trigger the navigation and/or opened the page from a homescreen icon and such?
** That doesn't matter since the clientId doesn't represent the navigated from document.
* What about cross origin non-subresource fetches?
** They won't get intercepted, so that is moot.
* What if the navigated to document ends up being controlled by another service worker?
** That's OK too, since you can already get that clientId through includeUncontrolled.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/808#issuecomment-169150678