- From: Jake Archibald <notifications@github.com>
- Date: Thu, 26 Oct 2017 07:52:26 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1216@github.com>
Based on what we discussed in https://github.com/w3c/ServiceWorker/issues/1091: ```js addEventListener('fetch', event => { event.respondWith(…); if (!event.resultingClientId) return; event.waitUntil(async function () { const client = await clients.get(event.resultingClientId); // client may be a reserved client. // Therefore this next line may fail: client.navigate(…); }()); }); ``` You'll get a real client in the weird `about:blank` case, otherwise you'll get a reserved client, where `.navigate` fails. It's got me wondering if we shouldn't expose reserved clients at all. Instead, `clients.get(resultingClientId)` should wait until the client exists before resolving with a real client (or resolve undefined if the client will never exist). This way we don't have to deal with queuing `postMessage`, and developers don't have to worry about what reserved clients can & can't do. The downside is you could create a deadlock: ```js addEventListener('fetch', event => { event.respondWith(async function () { const client = await clients.get(event.resultingClientId); return new Response(…); }()); }); ``` This would deadlock for all navigations, except in the case of the `about:blank` edge case. Given that deadlock here is the common scenario, it doesn't bother me too much. It'd be easy spotted during development. -- 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/1216
Received on Thursday, 26 October 2017 14:52:49 UTC