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

See steps 22 to 24 in:

https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm

And step 9 in:

https://w3c.github.io/ServiceWorker/#handle-functional-event-algorithm

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
>
>
>