Re: [w3c/ServiceWorker] consider allowing a non-scope identifier for registrations (#1512)

Moving scope to a service worker level thing sounds fine, and I agree it should be exposed to script. 

> skipWaiting() will cause the new service worker to activate and any existing controlled clients not covered by the new scope become uncontrolled via a controlchange event.

I agree this as the only sensible thing to do. However, I don't think `skipWaiting` should cause clients to switch to another service worker registration, or switch from no registration to a registration. We have `clients.claim` for that.

> Moving a registration to a scope that exactly matches another existing registration will replace that registration. From an API perspective this is similar to calling register() again on the same scope with a different script URL, etc. I think throwing would be unexpected.

I don't think this is the right model. Calling `register` with a different script URL is altering one registration, whereas the scenario above is moving one registration and unregistering another.

```js
const reg1 = await navigator.serviceWorker.register('/sw1.js');
const reg2 = await navigator.serviceWorker.register('/sw2.js', { id: 'foo' });
```

I'm assuming that:

- `reg1` has an id of `/` and a scope of `/`
- `reg2` has an id of `foo` and a scope of `/`

Either:

- The second register fails because there's already a registration at that scope.
- The first registration implicitly unregisters.

In the second case, `reg1` would continue to control clients until they go away, or `reg2` claims those clients.

My only worry about this behaviour is it involves data loss. Things like push registrations, bg fetch, associated with `reg1` would be removed. Could that be a gotcha?

-- 
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/1512#issuecomment-667064665