- 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