- From: Jungkee Song <notifications@github.com>
- Date: Thu, 22 Jun 2017 04:20:37 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1091/310351511@github.com>
@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