Create a Kill Service Workers algorithm

[asakusuma]

Intended to be a killswitch mechanism for all service workers associated with an origin. In the short term, designed to be used directly by Clear Site Data.

1. "Unclaim" all service workers for the origin. In other words, ensure no clients are controlled by any service worker under the origin
2. Terminate all in-flight tasks, but allow fetch tasks to fallback to network
3. Immediately unregister all registrations under the origin

Context:
#614 (comment)

Eventually will resolve:
w3c/webappsec-clear-site-data#54

cc @jungkees @mattto @jakearchibald

---

Preview | Diff

[jakearchibald]

I'm digging into this. It feels like we need to define what happens when various algorithms are cancelled halfway through. Eg, what happens if a service worker is killed half way through install, fetch, etc.

[asakusuma]

I agree that we need to define what happens to in-flight tasks. However, for the purpose of a killswitch, it would be nice if that definition was centralized/global, rather than relying on the individual design of each algorithm. Is it possible to just drop every task on the floor, have fetches fallback to network, nuke a top level state container, and let GC do its thing?

[asakusuma]

TODO:

• Either specify a time limit for pending promises, or update wait until language to allow killing pending promises without a grace period
• Close any notifications associated with service workers
• Terminate any running background fetches

[jakearchibald]

We'd also need to do something about ongoing background fetches.

This is why I think we need to spec this a little more explicitly rather than try and hand-wave it.

However, these aren't problems created by Clear Site Data. We just haven't been clear about how registrations are cleaned up so far.

[asakusuma]

Makes sense. I've added the background fetches to the TODO.

I'm hoping we can apply the fetch group concept and do something similar for service workers.