Intent to Ship: Service Worker's skipWaiting and oncontrollerchange

[Kenji Baheux]

Contact emails

Engineering: xiang...@intel.com (PM: kenji...@chromium.org)

Spec

Editor's draft (W3C Public Working Draft)

Summary

This intent to ship adds the following APIs to the Service Worker subset we shipped in M40[1]:

• ServiceWorkerContainer’s oncontrollerchange

• ServiceWorkerGlobalScope’s skipWaiting

       (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

https://groups.google.com/a/chromium.org/d/msg/blink-dev/Du9lhfui1Mo/HxL_pS7Cl-AJ

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

Yes.

Debuggability

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.

Compatibility Risk

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?

http://crbug.com/440285

Link to entry on the feature dashboard

http://www.chromestatus.com/feature/6561526227927040

[1]: links to past Intent to Ship

- Intent to ship Service Worker

- Intent to ship Cache API for Service Worker

----

Xiang, thanks for landing these 2 APIs!

[PhistucK]

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

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Has there been explicit discussion on the standards lists of these two additions?

[Alex Russell]

There has been quite a lot of discussion about the design of the `skipWaiting` feature (formerly called `replace()`). The current design is the result of long threads:

   https://github.com/slightlyoff/ServiceWorker/search?q=replace&type=Issues&utf8=%E2%9C%93

See the proximate decision discussion here:

   https://github.com/slightlyoff/ServiceWorker/issues/518

Regards

[Alex Russell]

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.

 

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

It's only as tricky as application updates are in general. We've worked hard to ensure that there's no non-inherent complexity in the model. 

[Philip Jägenstedt]

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?

Philip

[PhistucK]

Comments inline.

☆PhistucK

On Fri, Dec 12, 2014 at 1:13 AM, Alex Russell <sligh...@google.com> wrote:

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.

I am worried. ​This is inconsiderate to early adopters. Removing a property that has never shipped is far easier (and makes total sense) than removing it afterwards. I feel it is ridiculous to even utter such a weird short term road map ("ship something, remove it six weeks later" - huh?!). Especially when you know developers really love 'using stuff they are not supposed to use'.

 

 

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.

So, say example.com has a Service Worker​, every (non AJAX) navigation would trigger an update check ?

That feels pretty wasteful in terms of mobile data...

[Chris Harrelson]

LGTM

PhistucK, regarding your concern: a bit of instability is unavoidable when introducing a big new feature like this. It's the price you pay for rolling out the feature in an agile way (in the good sense - meaning we can fix design and implementation issues quickly), as well as for being an early adopter.

We're all trying our best not to break content, or introduce bad APIs. There is always a tension between existing content and evolving the platform.

Chris

[PhistucK]

I would agree with you if Chrome 40 were a few days away from going stable, but since it is fairly early in the beta phase, not removing it seems very ridiculous.

☆PhistucK

[Kenji Baheux]

Hi Philip,

On Sat Dec 13 2014 at 12:06:37 AM Philip Jägenstedt <phi...@opera.com> wrote:

Do you have a CL prepared for this to make it very concrete which
changes we're talking about?

Here is the relevant CL with extra links: https://codereview.chromium.org/717353004/  

 

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?

We intended to have these behind a RuntimeEnabledFeatures (see these extra API for ServiceWorkerClients).

However, we have a release guideline to enable new features 2 weeks before the branch cut (including tentative features/APIs) and the CLs made it just in time. So even if we had a flag, we would have been in a similar state.

We'll put these back behind a flag if we fail to obtain the 3x LGTMs before the branch cut.

> email to blink-dev+unsubscribe@chromium.org.

[Matt Falkenhagen]

2014-12-13 0:44 GMT+09:00 PhistucK <phis...@gmail.com>:

On Fri, Dec 12, 2014 at 1:13 AM, Alex Russell <sligh...@google.com> wrote:

On Thu, Dec 11, 2014 at 1:22 AM, PhistucK <phis...@gmail.com> wrote:

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.

So, say example.com has a Service Worker​, every (non AJAX) navigation would trigger an update check ?

That feels pretty wasteful in terms of mobile data...

Typically the update check will hit the browser cache. The browser cache is bypassed if 24 hours elapsed since the last network fetch, as mandated by the spec.

So the typical way a web author can update is by rolling out the updated Service Worker script to the original URL. The user will receive the update in about a day (if the site is being navigated to). The additional wrinkle is that by default this updated script does not become activated until the user closes all documents controlled by the old script. skipWaiting() gives the author the ability to bypass this waiting period and immediately activate the updated script, making it the controller of the current documents as well as new ones.

[Philip Jägenstedt]

Thanks Kenji, that explains the apparent already-shipped-ness of
skipWaiting and oncontrollerchange.

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?

Out of caution, I reached out to some Mozilla folks to see if they had
any concerns:

On Fri, Dec 12, 2014 at 8:38 PM, Philip Jägenstedt <phi...@opera.com> wrote:
> I'm reaching out to see if you have any concerns with these or any
> other parts of Service Workers? Is spec feedback you have been taken
> into account? Do you have any idea of the timeframe for when Service
> Workers will be shipped in Firefox?

The replies:

On Mon, Dec 15, 2014 at 5:25 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> We are working on the implementation of Service Worker on a project
> branch which is why you can't find most of the implementation in
> Nightly yet, but we are trying to merge the existing work back to the
> main development tree very soon.
>
> I think the only contending spec issue is
> https://github.com/slightlyoff/ServiceWorker/issues/566 which was spun
> off of the lengthy discussion in
> https://github.com/slightlyoff/ServiceWorker/issues/445. I wish that
> we could make progress on that sooner. :)

On Mon, Dec 15, 2014 at 6:20 PM, Nikhil Marathe <nsm.n...@gmail.com> wrote:
> I'll defer to Anne for the spec stuff since he has been most in touch with
> it the last couple of months.
> For the timeframe, we are beginning to land patches on Firefox Nightly, so
> ideally by January we'll be shipping a subset of SW APIs on Nightly, but
> preffed off in release builds.

In other words, no specific concern about this intent.

However, the multiple scopes issue is unfortunate, see also Ehsan's
message to blink-dev in October:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/QfxPGw0kJW8/Xm67_ftW3jgJ

The thread quickly died, and AFAICT the risk of shipping incompatible
implementations remains. The GitHub issue has seen recent activity,
but prioritizing its resolution would be helpful.

Philip

>> > email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM2

[Matt Falkenhagen]

2014-12-16 8:35 GMT+09:00 Philip Jägenstedt <phi...@opera.com>:

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?

Thanks for examining the spec. My reading is that if the skip waiting flag was set by the time Install reaches 4.7.9 ("If registration's waiting worker's skip waiting flag is set"), the worker is activated and the rest of the algorithm is aborted. On the other hand, if skipWaiting() is called after Install reached that point, the worker is activated via skipWaiting() step 1.2.1 ("Run Activate algorithm..."). This is how we implemented it: skipWaiting() activates immediately if you're already installed, or else activates once installation completes.

I do think there is a minor spec bug, though, that skipWaiting() by an installed worker doesn't abort the "Wait until no service worker client..." step of Install. I'll file a spec bug.

[Philip Jägenstedt]

Thanks Matt, I'll follow along in
https://github.com/slightlyoff/ServiceWorker/issues/594

With that, LGTM3.

Philip

[Chris Harrelson]

Hi PhistucK,

You're referring specifically to merging the removal of ServiceWorkerClient.id into Chrome 40, correct? Apologies for not reading your emails closely enough.

I think that makes sense, and is easy to do. I chatted with jsbell@ and he agreed to merge this CL.

Chris

[PhistucK]

Yes, I meant specifically to the id attribute.

I do not see a merge request label or any merge process in the issue, though. Just making sure this does not skip through the cracks. :)

Thank you for following up!

☆PhistucK

[Joshua Bell]

Just merged; should disappear from the next canary build.

Thanks for picking those nits, PhistucK!

[PhistucK]

Great! Thank you very much for the quick follow up.

☆PhistucK

[jung...@gmail.com]

2014년 12월 17일 수요일 오후 10시 59분 42초 UTC+9, Philip Jägenstedt 님의 말:

The above issue has been fixed. Thanks for spotting!

 

With that, LGTM3.

Philip