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

> @wanderview , thanks for sharing the tests! Both Firefox and Chrome respond with 'failure: could not find about:blank client' for all the cases. As you pointed earlier, the about:blank window either isn't created yet or not exposed to matchAll in some reason at least.

Correct, but I think this behavior is what we've agreed on in the spec so far, right?  This test passes in firefox with the patches I have in progress at:

https://bugzilla.mozilla.org/show_bug.cgi?id=1293277

> Let's start with what we agree on first. The final client should be the about:blank client. Right? That client is created when the nested browsing context is created and later reused for the fetched document.

Agreed.

> In #1091 (comment), you said clientId should be the top-level client (foo.html in the example.) But I think it should be that of the about:blank client. The reason is the fetch request's client is the about:blank client. Do you agree?

Honestly I'm not sure any more.  I thought it would have used the client for the global of the script that made the change, but maybe this has changed recently with @domenic's changes.

In any case, I agree it should be some existing Client which we determined to have "caused" the navigation to start.

> Beyond that, what reservedClientId should represent here and whether we'll introduce initialClientId are the further discussion points.

Right.

And the main reason I see for not just putting an initial about:blank client in `reservedClientId` is the issue with `postMessage()` not being queued until the final load like you get with a real reserved client.

I guess if we made real reserved clients not queue message events, then this problem would go away.

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