Re: [ServiceWorker] A worker that fails to activate should relinquish its controllees (#659)

As a developer, I'd except `r.active` to be null if there's no worker to send events like `fetch` to.

I'd been against having registrations with no workers in the past, but I'm coming around to this idea. Here are the issues:

**We keep trying to install/activate the same worker** each time `navigator.serviceWorker.register` is called, even if the script hasn't changed. This is because we've thrown away the broken worker so we can't do a byte-for-byte check. This could be fixed by retaining the broken worker internally for checking.

**This makes things difficult for other specs** such as the [push API](https://w3c.github.io/push-api/#the-push-event). Right now they can assume there will always be an active worker to fire events in, as they require an active worker to set up push registration. I'm not sure what the best way to fix this is, I guess they'll have to manage their own queuing or simply drop push messages while the SW is broken.

**Only .register can trigger a retry**. This isn't a problem now, but I think we want the `push` event (and maybe others) to be able to trigger soft updates. This is because sites may use another origin for push management, than the origin users are likely to visit frequently. Eg, if a site has multiple international sites, they may pick one for `push`, if a site cannot yet fully switch to `https`, they may use a small `https` origin for user profile & push. The answer here is to remove step 5 of [soft update](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#soft-update-algorithm), but I don't remember if there was a good reason we make that check.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/659#issuecomment-87778808