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.

> @jakearchibald, can you refresh my memory as to why we needed reserved Client ID? Can we get the same thing another way without actually referencing not-quite-there-yet Clients?

In my memory, the major use case was to open up an ability to manage caches per-client basis. A reservedClientId and a targetClientId can give a clue to create and delete caches, respectively. Another use case was messaging. I don't recall anything else.

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.

In https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-300817825, 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?

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

/cc @jakearchibald 

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

Received on Thursday, 22 June 2017 11:21:25 UTC