Re: [w3c/ServiceWorker] Confusion around new events after skipWaiting (#1295)

@mattto I assume you meant to say "to **prevent** a 'lame duck' worker continue being the active worker"

If we are going to pick a single approach, I would prefer the https://github.com/w3c/ServiceWorker/issues/1292 approach to codifying the "lame duck" prevention for `skipWaiting`, but I think it would be good to also codify a global limit for how long any outgoing worker is allowed to stay alive. In other words, handle both the "skipWaiting" and "all clients closed" scenarios.

Another option would be to start activation immediately in both scenarios. Both the [fire functional event](https://w3c.github.io/ServiceWorker/#fire-functional-event-algorithm) and [on fetch request](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm) algorithm have `If activeWorker’s state is activating, wait for activeWorker’s state to become activated.` steps. This would mean that for events that are already mid-flight, their handling worker would change from active to redundant mid-flight.

-- 
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/1295#issuecomment-428721903