- From: Mike Pennisi <mike@bocoup.com>
- Date: Tue, 14 Mar 2017 12:26:25 -0400
- To: public-webapps@w3.org
> Most efforts to stop bad behavior are concerned about Service Workers that > try and remain alive indefinitely without a page. So that "self.postMessage" idea is out. Got it. > It's a fairly common idiom in the existing ServiceWorker WPT tests and > browser-specific tests (at least for Gecko) to use waitUntil in a SW to keep > it alive until the page says it should be terminated. Unfortunately, this pattern isn't consistently applied (see, for example [1]). I'm hoping that this behavior can be built in to the tooling (with some opt-out mechanism) so that we can address this consistently and so that future contributors don't unknowingly create new race conditions. > For awareness, Gecko's current timeout settings can be found here That's great! Thanks for the reference :) > Having said all that, it sounds like you want to keep a single ServiceWorker > alive for an extended period of time, and I'm not sure I get why that is. See [1] for an example. Service worker termination is a variable that I'd like to control for in these tests. In well-structured application contexts, this detail shouldn't matter. In the tests, though, I'd like to be able to track a single worker through its lifecycle. I'm hoping this will help to catch bugs that you wouldn't necessary be able to observe through the `statechange` API alone (such as events firing on redundant works, etc.). Thanks for the feedback! [1] https://github.com/w3c/web-platform-tests/blob/52d497aebf6927a64d8add634b10b113118b9e2c/service-workers/service-worker/ServiceWorkerGlobalScope/resources/registration-attribute-worker.js
Received on Tuesday, 14 March 2017 16:27:00 UTC