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

Thanks, Ben! These invocations of "Soft Update" are exactly what I was 
missing.

I think there is some non-determinism when it comes to the exact timing from
those other algorithms, since the invocation is consistently queued as a 
job.
But the variability doesn't end there. The definition of Soft Update 
includes
the following text:

 > The user agent may call this as often as it likes to check for updates.

And further:

 > Note: Implementers may use the force bypass cache flag to aid 
debugging (e.g.
 > invocations from developer tools), and other specifications that extend
 > service workers may also use the flag on their own needs.

If I'm interpreting them correctly, these two details mean that any of a
Service Worker's lifecycle events (as well as a registration's `updatefound`
event) may fire at any time.

I don't believe this presents a problem for application developers. The 
design
of the Service Worker API strongly discourages programming patterns that 
rely
on persistent state, so this kind of variability shouldn't have any 
bearing on
normal operation.

But to be able to test the implementation and validate that browsers are
working as per spec (and again, assuming my assessment is correct), this is
problematic. It makes it impossible to make any assertions about lifecycle
events observed over a given time frame. Any test for "normal" operation 
(e.g.
call `registration.update()` and observe `updatefound` followed by 
`install`,
followed finally by `active`) could be interrupted by an independent 
invocation
of Soft Update.  Would you agree? Or have I tripped myself up somewhere 
along
the way?


On 03/09/2017 08:01 PM, Ben Kelly wrote:
> 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 
> <mailto: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
>
>
>