Re: [w3c/ServiceWorker] consider Client behavior for windows where initial about:blank is replaced with a loaded document (#1091)

> I don't like using reservedClientId to represent a client that already exists, but my objection is only in the naming. I'm happy to drop reservedClientId and replace it with @wanderview's initialClientId, which (unless I'm mistaken) represents "The client ID of the resulting navigation/worker", which may already exist like in the about:blank case. I'm still not convinced of the naming though. resultingClientId anyone?

Storing initial and reserved in the name of resultingClientId sounds fine to me. This would mean we effectively change the meaning of the attribute to *resulting* client's id in all cases. That said, I'd like to clarify the name and the meaning of targetClientId too. If we expect it to be a *replaced* client, how about naming it replacedClientId and set it to null in the initial about:blank case. (Then, `event.request.mode === "navigate" && event.replacedClientId === ""` would imply it's a navigate of nested/auxilary browsing context with the initial client, right?)

> We handle this with reserved clients by buffering messages until the client is created & the port is started (either explicitly by calling startMessages(), implicitly by assigning to onmessage, or after DOMContentLoaded).

(Just to clarify: That changes were made to address https://github.com/w3c/ServiceWorker/issues/728: the race between client.postMessage in openWindow().then() in a SW and event listener setup in a loading client. For reserved clients, we have an open issue: https://github.com/w3c/ServiceWorker/issues/1035 - as it's even before a global is created.)

As pointed, we need a solution for the initial client case anyway.

-- 
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/1091#issuecomment-311319920