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

> The client IDs aren't changing. In the fetch event, devs will see both the client and the reserved client, but the reserved client will be gone away when the navigate completes in this case. I mean only the about:blank client with its initial ID will be alive. I think it isn't odd as that's what happens.

How can the service worker tell whats going to happen here?  Does it have to execute code later to test to see which Client ended up being the final window?  This does not seem simpler to me.

> In this case, the reserved client is just used during the main resource fetch for matching a service worker, queueing postMessages, etc. I think the messages sent to the reserved client should be requeued to the about:blank client when the document is installed.

I'm sorry, but this seems a lot more complicated than just providing the correct Client in the first place.

As an implementer I'd like to keep the Client behavior as close to actual window creation behavior as possible.  It reduces special cases in an already complicated part of the system.

I'm not a web developer, but it seems to me that they would probably like to have a property they can reference that they can be certain will in fact become the final Client.

I'd really like to just put the initial Client ID in the `FetchEvent.reservedClient` property if we're in this about:blank replacement case, but early `postMessage()` is a problem.  Maybe we need some kind of "delay this message until the current load completes" API on postMessage.

-- 
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-309775895