This intent to ship adds the following APIs to the Service Worker subset we shipped in M40:API level detail)
These 2 APIs enable the following use case:
Forcing a newer Service Worker to take over an existing one
Suppose you mistakenly deployed a broken Service Worker to your users.
Without skipWaiting, you would have to ask your users to “close all example.com tabs” in order for the revised Service Worker script to take over the broken one. This is the default mode of operation where same-origin documents live their whole life with the same version of a Service Worker.
With skipWaiting, you will be able to fix these type of issues without any user intervention. In other words, this enables you to immediately push an update to a document, allowing it to change its Service Worker while still alive.
In addition, you can take advantage of the associated controllerchanged event to:
confirm that the revised Service Worker is now in control
optionally clean up after the broken Service Worker (e.g. delete bad caches)
Link to “Intent to Implement” blink-dev discussion
The spec and project used to be called Navigation Controller, but the name was changed to Service Worker.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
There's a Service Worker section in chrome://inspect that provides an overview of all the Service Workers and lets you inspect them. You can even do remote debugging of a Service Worker on a mobile device. chrome://serviceworker-internals provides information for Chromium developers to debug and diagnose Service Worker issues. Also, M41 has more descriptive error messages in the console when fetch() fails.
Pluses and minuses:
+ This is a relatively small addition to a shipping API surface
+ There's a second public working draft of the spec.
+ Mozilla is implementing Service Workers in Firefox, see bug 903441.
+ The team has been writing W3C testharness.js tests first, and only using Blink-specific tests for crashing and GC-related things. We plan to upstream these tests to W3C.
- AFAICT, skipWaiting is not yet implemented in Firefox (maple branch) so we can’t try our tests yet.
- The spec is under active development. However, most of the action is irrelevant to the scope of this intent to ship.
OWP launch tracking bug?
Link to entry on the feature dashboard
: links to past Intent to Ship
Xiang, thanks for landing these 2 APIs!
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Unrelated, but since you shared the presentation - is ServiceWorkerClient.id exposed to the web in Chrome 40? If so, perhaps merge the removal in order not to break implementations that may depend on it after a single release?
How does Chrome manage Service Worker updates?
Does it check in a certain interval (I see that getting a Service Worker to update is tricky, according to the presentation - is it tricky for web authors as well?)?
On Thu, Dec 11, 2014 at 1:22 AM, PhistucK <phis...@gmail.com> wrote:Unrelated, but since you shared the presentation - is ServiceWorkerClient.id exposed to the web in Chrome 40? If so, perhaps merge the removal in order not to break implementations that may depend on it after a single release?I'm not strictly worried about this. The window is only 6 weeks long and the total # of sites using Service Workers today is countable on two hands.
How does Chrome manage Service Worker updates?When a user navigates to a document controlled by a Service Worker, the registered script is checked for an updated version in the background.
Do you have a CL prepared for this to make it very concrete which
changes we're talking about?
Neither ServiceWorkerContainer.oncontrollerchange nor
ServiceWorkerGlobalScope.skipWaiting are behind
RuntimeEnabledFeatures, so is this an "Intent to not Revert," thereby
letting those changes reach the stable channel?
> email to firstname.lastname@example.org.
On Fri, Dec 12, 2014 at 1:13 AM, Alex Russell <sligh...@google.com> wrote:When a user navigates to a document controlled by a Service Worker, the registered script is checked for an updated version in the background.
Per spec, skipWaiting() sets the the skip waiting flag, which is
checked in the install algorithm. However, I see no mechanism for the
install algorithm to return to the step where the skip waiting flag
has an effect, can't it be stuck in "Wait until no service worker
client is using registration" at this point? The implementation isn't
a 1:1 translation of the spec, and I didn't dig deep enough to figure
out if this can actually happen as implemented. Can it?
With that, LGTM3.