- From: Ben Kelly <notifications@github.com>
- Date: Fri, 20 Nov 2015 06:24:39 -0800
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/785@github.com>
In Handle Fetch we have: ``` 14. Let activeWorker be registration's active worker. 15. If activeWorker's set of event types to handle does not contain fetch, return null. 16. If activeWorker's state is activating, then: 1. Wait for activeWorker's state to become activated. ``` So we can get a queue of pending fetch events waiting for the active worker to finish activating. Ok, good. But in the Activate algorithm we have: ``` 17. Run the Update State algorithm passing registration's active worker and activated as the arguments. 18. Pop the top element from activation queue. ``` Popping the element from activation queue can immediately cause the Activate algorithm to start over with the next worker in the activation queue. This can make the original activate worker the exiting worker. In this case it seems the queued fetch events get fired on the exiting worker. I guess Activate says to wait for the exiting worker to finish processing events, but it is this the behavior we want? Should the fetch events keep waiting until we have a stable activated worker? Essentially an activated worker and an empty activation queue? --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/785
Received on Friday, 20 November 2015 14:25:06 UTC