Intent to Ship Service Worker’s claim, Service-Worker-Allowed header, update

[Kenji Baheux]

Contact emails

Engineering: xiang...@intel.com, fal...@chromium.org

(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 already shipped:

• clients.claim()

• Service-Worker-Allowed header

• ServiceWorkerRegistration.update()

API level detail (Important: relevant changes for this intent to ship are in non-italic bold)

These APIs enable the following use cases:

Have your Service Worker run on the initial navigation

By default, a page that loads without a Service Worker controller will live its entire life without one, even if one is installed during that time. This means that if a page registers a Service Worker, it must be reloaded in order to be controlled by it. claim() makes this reloading unnecessary and allows for “SW runs on initial navigation” behavior.

Have your Service Worker control pages outside of its directory

As a safety precaution, by default a Service Worker’s maximum scope is restricted to the directory the script is served from. For example, “/static/resources/sw.js” can only control pages inside “/static/resources/*”. The Service-Worker-Allowed header allows sites to customize this path restriction. For example, a site may want “/static/resources/sw.js” to control all pages in the “/” scope. It would do so by serving the SW script with a “Service-Worker-Allowed: /” header.

Force a Service Worker to update

Suppose a site updates its Service Worker script and wants visitors to the site to receive the update ASAP. The site can use update() to request an update check. This allows the update to occur faster than the automatic 24 hour check.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS and Android, Android WebView)?

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, M42 has more descriptive error messages when Service Worker registration 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 and the main spec editor said he will start the process to get a third public working draft out soon.

+ Mozilla is implementing Service Workers in Firefox (main branch), 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, claim(), S-W-A are not yet implemented in Firefox so we can’t try our tests yet

- Firefox’s implementation apparently has update() on SWGlobalScope instead of SWRegistration (based on an old spec revision)

OWP launch tracking bug?

http://crbug.com/452816

Link to entry on the feature dashboard

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

[Kenji Baheux]

For reference, here is a link to the intent to publish a new WD: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0419.html

[Philip Jägenstedt]

These sound like nice additions, but I have some questions:

1. It looks like claim() isn't implemented quite per spec, which says "If the service worker is not an active worker, return a promise rejected with an "InvalidStateError" exception." Instead, the implementation seems to return a promise that won't ever be resolved in conditions which I'm not sure are equivalent. Will this be fixed before shipping?

2. Would there be any merit to moving that active worker check into the async part of the algorithm? With media elements, the order of API calls don't matter in some places, so that e.g. one can set src attributes, add/remove source elements or call load() and have the same source be used regardless, by doing the actual selection async. It's a bit complicated, but supposedly makes the API less brittle. Is there a similar situation with claim(), i.e. can there be a situation where the script author knows the worker becomes active shortly after the call to claim() and the only thing standing in the way is that sync check at the top? (If the spec is already in a kind of consistent state in this regard, please ignore me.)

3. It looks ServiceWorkerRegistration.update() isn't actually implemented yet?

4. In the design doc, Client.url is also in bold, but that's behind the experimental ServiceWorkerClientAttributes flag. That's not a part of this Intent to Ship, right?

Philip

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

[Joel]

On Saturday, February 7, 2015 at 3:57:43 AM UTC, Philip Jägenstedt wrote:

These sound like nice additions, but I have some questions:

1. It looks like claim() isn't implemented quite per spec, which says "If the service worker is not an active worker, return a promise rejected with an "InvalidStateError" exception." Instead, the implementation seems to return a promise that won't ever be resolved in conditions which I'm not sure are equivalent. Will this be fixed before shipping?

2. Would there be any merit to moving that active worker check into the async part of the algorithm? With media elements, the order of API calls don't matter in some places, so that e.g. one can set src attributes, add/remove source elements or call load() and have the same source be used regardless, by doing the actual selection async. It's a bit complicated, but supposedly makes the API less brittle. Is there a similar situation with claim(), i.e. can there be a situation where the script author knows the worker becomes active shortly after the call to claim() and the only thing standing in the way is that sync check at the top? (If the spec is already in a kind of consistent state in this regard, please ignore me.)

3. It looks ServiceWorkerRegistration.update() isn't actually implemented yet?

4. In the design doc, Client.url is also in bold, but that's behind the experimental ServiceWorkerClientAttributes flag. That's not a part of this Intent to Ship, right?

Philip

On Wed, Feb 4, 2015 at 12:41 AM, Kenji Baheux <kenji...@chromium.org> wrote:

Contact emails

Engineering: xiang...@intel.com, fal...@chromium.org

(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 already shipped:

• clients.claim()

• Service-Worker-Allowed header

• ServiceWorkerRegistration.update()

API level detail (Important: relevant changes for this intent to ship are in non-italic bold)

These APIs enable the following use cases:

Have your Service Worker run on the initial navigation

By default, a page that loads without a Service Worker controller will live its entire life without one, even if one is installed during that time. This means that if a page registers a Service Worker, it must be reloaded in order to be controlled by it. claim() makes this reloading unnecessary and allows for “SW runs on initial navigation” behavior.

Have your Service Worker control pages outside of its directory

As a safety precaution, by default a Service Worker’s maximum scope is restricted to the directory the script is served from. For example, “/static/resources/sw.js” can only control pages inside “/static/resources/*”. The Service-Worker-Allowed header allows sites to customize this path restriction. For example, a site may want “/static/resources/sw.js” to control all pages in the “/” scope. It would do so by serving the SW script with a “Service-Worker-Allowed: /” header.

Is this going to include any form of the "kill switch" we started discussing in https://github.com/slightlyoff/ServiceWorker/issues/614? I don't think we ever settled on how it should work, so I understand if the answer is 'no'.  

Force a Service Worker to update

Suppose a site updates its Service Worker script and wants visitors to the site to receive the update ASAP. The site can use update() to request an update check. This allows the update to occur faster than the automatic 24 hour check.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS and Android, Android WebView)?

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, M42 has more descriptive error messages when Service Worker registration 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 and the main spec editor said he will start the process to get a third public working draft out soon.

+ Mozilla is implementing Service Workers in Firefox (main branch), 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, claim(), S-W-A are not yet implemented in Firefox so we can’t try our tests yet

- Firefox’s implementation apparently has update() on SWGlobalScope instead of SWRegistration (based on an old spec revision)

OWP launch tracking bug?

http://crbug.com/452816

Link to entry on the feature dashboard

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

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

[Matt Falkenhagen]

On Sun Feb 08 2015 at 3:18:19 AM Joel <j...@chromium.org> wrote:

Have your Service Worker control pages outside of its directory

As a safety precaution, by default a Service Worker’s maximum scope is restricted to the directory the script is served from. For example, “/static/resources/sw.js” can only control pages inside “/static/resources/*”. The Service-Worker-Allowed header allows sites to customize this path restriction. For example, a site may want “/static/resources/sw.js” to control all pages in the “/” scope. It would do so by serving the SW script with a “Service-Worker-Allowed: /” header.

Is this going to include any form of the "kill switch" we started discussing in https://github.com/slightlyoff/ServiceWorker/issues/614? I don't think we ever settled on how it should work, so I understand if the answer is 'no'.  

No, I think that will have to be another intent to ship, as it's not decided yet.

[Alex Russell]

Hey Joel,

This doesn't include any implementation for a kill switch. I'm hopeful we'll reach a conclusion in the issue and can get an implementation done quickly, but it isn't part of this intent. I don't think anything in this feature will negatively impact our ability to add a kill-switch (either using a non-URL value or a separate header).

Regards

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

[Kenji Baheux]

Hi Philip,

I believe that Matt responded to some of your questions (although I didn't see his response from the web interface yet).

Here are answers for the logistic questions:

3. It looks ServiceWorkerRegistration.update() isn't actually implemented yet?

This method was asked by one of our ServiceWorker customers but we are still trying to confirm if this will help them solve their use case.

In terms of implementation complexity, this should be pretty straightforward given that the underlying logic is already implemented as part of handling the natural lifecyle of Service Workers.

 

4. In the design doc, Client.url is also in bold, but that's behind the experimental ServiceWorkerClientAttributes flag. That's not a part of this Intent to Ship, right?

You're right. Good catch!

(fixed)

[Matt Falkenhagen]

On Tue Feb 10 2015 at 10:15:49 AM Kenji Baheux <kenji...@chromium.org> wrote:
>
> Hi Philip,
>
> I believe that Matt responded to some of your questions (although I
> didn't see his response from the web interface yet).

I think the spam filter ate my response. Trying again, this time
edited to not have links:

On Sat Feb 07 2015 at 12:57:39 PM Philip Jägenstedt <phi...@opera.com> wrote:
>
> These sound like nice additions, but I have some questions:
>
> 1. It looks like claim() isn't implemented quite per spec, which says
> "If the service worker is not an active worker, return a promise
> rejected with an "InvalidStateError" exception." Instead, the
> implementation seems to return a promise that won't ever be resolved in
> conditions which I'm not sure are equivalent. Will this be fixed before
> shipping?

The active worker check is performed in
ServiceWorkerVersion::OnClaimClients. The line you link to is unrelated
to the check; it's a mitigation for a generic bug when a crash can occur
after a worker thread is terminated. More information is on
crbug.com/413518.

> 2. Would there be any merit to moving that active worker check into
> the async part of the algorithm? With media elements, the order of API
> calls don't matter in some places, so that e.g. one can set src
> attributes, add/remove source elements or call load() and have the same
> source be used regardless, by doing the actual selection async. It's a
> bit complicated, but supposedly makes the API less brittle. Is there a
> similar situation with claim(), i.e. can there be a situation where the
> script author knows the worker becomes active shortly after the call to
> claim() and the only thing standing in the way is that sync check at the
> top? (If the spec is already in a kind of consistent state in this
> regard, please ignore me.)

I think typically the script writer will call claim() in the 'activate'
event handler, which is called when the worker becomes active. So I
don't think the sync check will be a bother.

> 3. It looks ServiceWorkerRegistration.update() isn't actually
> implemented yet?

Correct. We can make it another intent if you'd like to review the
implementation before shipping. But auto-update behavior is already
implemented so I don't expect update() to be so tricky.

[Philip Jägenstedt]

On Tue, Feb 10, 2015 at 8:41 AM, Matt Falkenhagen <fal...@chromium.org> wrote:
>
> On Tue Feb 10 2015 at 10:15:49 AM Kenji Baheux <kenji...@chromium.org> wrote:
> >
> > Hi Philip,
> >
> > I believe that Matt responded to some of your questions (although I
> > didn't see his response from the web interface yet).
>
> I think the spam filter ate my response. Trying again, this time
> edited to not have links:
>
> On Sat Feb 07 2015 at 12:57:39 PM Philip Jägenstedt <phi...@opera.com> wrote:
> >
> > These sound like nice additions, but I have some questions:
> >
> > 1. It looks like claim() isn't implemented quite per spec, which says
> > "If the service worker is not an active worker, return a promise
> > rejected with an "InvalidStateError" exception." Instead, the
> > implementation seems to return a promise that won't ever be resolved in
> > conditions which I'm not sure are equivalent. Will this be fixed before
> > shipping?
>
> The active worker check is performed in
> ServiceWorkerVersion::OnClaimClients. The line you link to is unrelated
> to the check; it's a mitigation for a generic bug when a crash can occur
> after a worker thread is terminated. More information is on
> crbug.com/413518.

Oh, I see.

> > 2. Would there be any merit to moving that active worker check into
> > the async part of the algorithm? With media elements, the order of API
> > calls don't matter in some places, so that e.g. one can set src
> > attributes, add/remove source elements or call load() and have the same
> > source be used regardless, by doing the actual selection async. It's a
> > bit complicated, but supposedly makes the API less brittle. Is there a
> > similar situation with claim(), i.e. can there be a situation where the
> > script author knows the worker becomes active shortly after the call to
> > claim() and the only thing standing in the way is that sync check at the
> > top? (If the spec is already in a kind of consistent state in this
> > regard, please ignore me.)
>
> I think typically the script writer will call claim() in the 'activate'
> event handler, which is called when the worker becomes active. So I
> don't think the sync check will be a bother.

Very well, no need to complicate things if it seems unlikely to ever help.

> > 3. It looks ServiceWorkerRegistration.update() isn't actually
> > implemented yet?
>
> Correct. We can make it another intent if you'd like to review the
> implementation before shipping. But auto-update behavior is already
> implemented so I don't expect update() to be so tricky.

There's no need for a separate Intent to Implement, I just wanted to
check that this wasn't an oversight or something.

LGTM!

Philip

[Dimitri Glazkov]

LGTM2.

:DG<

[Philip Rogers]

LGTM3

On Tue, Feb 10, 2015 at 12:34 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM2.

:DG<

[Joel Weinberger]

On Mon Feb 09 2015 at 4:40:50 PM Alex Russell <sligh...@google.com> wrote:

Hey Joel,

This doesn't include any implementation for a kill switch. I'm hopeful we'll reach a conclusion in the issue and can get an implementation done quickly, but it isn't part of this intent. I don't think anything in this feature will negatively impact our ability to add a kill-switch (either using a non-URL value or a separate header).

Yup, sounds good. Like I said, I was just curious. LGTM from security.