W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2017

Re: [service-workers] A pattern for preventing worker termination indefinitely

From: Mike Pennisi <mike@bocoup.com>
Date: Tue, 14 Mar 2017 12:26:25 -0400
To: public-webapps@w3.org
Message-ID: <6acdae27-258b-7ab1-1ede-68a6bc7a4fc7@bocoup.com>
 > Most efforts to stop bad behavior are concerned about Service Workers 
 > 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 
I'm hoping that this behavior can be built in to the tooling (with some 
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 
 > 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!

Received on Tuesday, 14 March 2017 16:27:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:15:04 UTC