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

Re: [service-workers] Aggressive worker fetching in Chrome

From: Ben Kelly <bkelly@mozilla.com>
Date: Thu, 9 Mar 2017 20:01:41 -0500
Message-ID: <CA+1UsbR1T2aZksU2V1b-a_9wOs-+m+MGbfc22zpGEtpexQrWbA@mail.gmail.com>
To: Mike Pennisi <mike@bocoup.com>
Cc: Webapps WG <public-webapps@w3.org>
See steps 22 to 24 in:


And step 9 in:


There is some flexibility as to when to actually trigger the update,
though.  I believe both chrome and firefox wait until after the load
event.  (Firefox might be 1 second after dom loaded and chrome might be 1
second after load event.)  In theory we should maybe switch this stuff to
use requestIdleCallback() style semantics.

I believe there should be WPT tests for some of these already.

On Thu, Mar 9, 2017 at 7:50 PM, Mike Pennisi <mike@bocoup.com> wrote:

> Hello all,
> I'm working on some tests for ServiceWorkers in the Web Platform Tests
> suite,
> and I was wondering about the behavior I'm seeing from Chrome.
> Basically, I am seeing the browser check for Service Worker script updates
> after handling a fetch request. I am able to observe this because the
> server
> is modifying a JavaScript comment in the requested source file for every
> request, so simply registering a worker, waiting for it to activate, and
> then
> triggering its `fetch` handler results in an (eventual) `updatefound`
> event on
> the registration. The same Service Worker is used throughout--no
> termination
> occurs between initial registration and handling of the `fetch` (verified
> by
> logging to the developer's console at the top-level of the script).
> I've been looking for spec language that dictates this behavior, but I
> haven't
> been able to find anything so far. Beyond certain rules such as the 24-hour
> expiry, the strategy for invalidating Service Worker scripts seems like it
> could support implementation-specific tuning, so I wouldn't be surprised if
> Chrome's behavior was not formally specified but still allowable. I wanted
> to
> verify here, though, because I'll need to account for that kind of
> variation in
> these tests!
> Thanks,
> Mike
Received on Friday, 10 March 2017 01:02:16 UTC

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