[w3c/ServiceWorker] Should we expose reserved clients? (#1216)

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