Intent to ship: Service Worker

[Kenji Baheux]

Contact emails

kenji...@chromium.org, domi...@chromium.org

Spec

https://slightlyoff.github.io/ServiceWorker/spec/service_worker/

Summary

Service Worker is a new kind of Web Worker that does persistent background event processing. The first kind of event is called "onfetch" and lets the Service Worker handle a page's network requests.

We're proposing to ship the following subset of what is defined in the spec:

• register Service Workers and manage registrations

• communicate with running Service Workers using postMessage

• enumerate related documents (“clients”)

• handle a client’s network requests

• talk to the network with a modern replacement for XHR called fetch()

(API level detail.)

Notably, the Cache API as defined in the spec is not in the subset covered by this Intent. We intend to file a separate Intent once both the blink implementation and spec have stabilized.

The scope of this Intent addresses the following use cases:

1. Reducing page load latency

For users who have previously visited a site, Service Workers can accelerate page loading. See this comparison of the user experience between No Service Worker and With Service Worker. How Service Workers can reduce latency is described in this overview. You can experience it yourself in the demo below.

2. Offline

Service Workers move the web forward by letting developers provide compelling experiences, even while offline. Service Workers use JavaScript to mediate offline/network interaction. In the demo below, JavaScript races concurrent requests to the cache and the network to handle "airplane mode offline" (use cache), "elevator ride offline" where the network is available but slow (use cache, update in the background, and give the user a prompt about fresh posts) and online (use network.)

3. Extensibility

Future web platform features such as Push Messaging and Background Sync use Service Worker to process events. Shipping Service Workers will help get these new capabilities into the hands of web developers.

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.

Demo link

Pre-requisites:

• Chrome canary with chrome://flags/#enable-experimental-web-platform-features enabled

• Network connection with speed characteristics close enough to those of a mobile network. You could use Chrome DevTools Emulation, Network, Limit network throughput feature. Or yank your ethernet cable occasionally.

Steps:

1. Open Trained to Thrill in Chrome canary (with experimental web platform features enabled)

2. Open in a browser with no support for Service Worker. Observe that the demo still works. It’s trivial to support Service Worker where available while avoiding any impact on the user experience elsewhere.

3. Close both browsers.

4. Open Trained to Thrill again in both browsers. Notice how fast the experience was in Chrome canary?

5. Disconnect from your network.

6. Hit reload in both browsers. Notice that the app still works in Chrome canary.

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.

Compatibility Risk

Pluses and minuses:

+ There's a first public working draft of the spec.

+ Mozilla is implementing Service Workers in Firefox, see bug 903441.

+ We semi-regularly reconcile the spec and our implementation. We have a defined process for that.

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

- The pass rate of the test suite in Firefox is low, although that’s mostly because some things are not implemented there yet.

- The spec is under active development but most of the action is irrelevant to the scope of this intent to ship.

OWP launch tracking bug?

http://crbug.com/364627

Link to entry on the feature dashboard

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

[Dimitri Glazkov]

LGTM.

[kenji...@google.com]

Let me update the specification section, to make it clear that this is a w3c work product:

Spec

Editor's Draft

W3C public working draft    

[Boris Zbarsky]

On 10/14/14, 9:48 PM, Kenji Baheux wrote:
> - The pass rate of the test suite in Firefox is low, although that’s
> mostly because some things are not implemented there yet.

It's mostly because the "spec" is impossible to actually base an
implementation on as far as I can tell. Which makes me confused about
the claim about you reconciling your implementation with the spec....
unless you mean that you vaguely update the spec to more closely but not
quite match your implementation?

Given the spec situation, I strongly suspect that your implementation is
not compatible with our implementation, though I would welcome evidence
to the contrary.

I'm not aware of plans on our side to enable service workers until the
spec has gained some measure of sanity and we've had a chance to check
our implementation against the result, for what it's worth.

-Boris

[Jochen Eisinger]

Boris, can you give a concrete example of something that is not possible implement? I guess not everybody here is as familiar with the spec as you or the service worker team is.

thanks

-jochen

[Anne van Kesteren]

On Wed, Oct 15, 2014 at 9:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:
> Boris, can you give a concrete example of something that is not possible
> implement? I guess not everybody here is as familiar with the spec as you or
> the service worker team is.

Well, of the issues Google has identified as blocking shipping, 15 are
still open:

https://github.com/slightlyoff/ServiceWorker/labels/impacts%20MVP

Overall there are over a 100 issues open, most of which are not v2 as
far as I know. E.g. one thing that is quite clearly undefined is the
life cycle of a service worker. The specification makes handwavy
references to algorithms defined for dedicated workers and shared
workers, without going into detail what those mean for service
workers. This particular one I've been raising for months, with no
sign that the specification is getting any closer towards addressing
it. It's quite a mess.


--
https://annevankesteren.nl/

[Kenji Baheux]

The impact MVP does not strictly map to ship blockers. Also, issues that relates to the cache should be filtered out.

I will follow up with a more accurate picture soon.

[Boris Zbarsky]

On 10/15/14, 3:05 AM, Jochen Eisinger wrote:
> Boris, can you give a concrete example of something that is not possible
> implement?

I didn't say "impossible to implement".

I said "impossible to base an implementation on". As in, if you
implement what the spec says, the resulting behavior will be wrong.
There is a subtle difference; the latter is a somewhat weaker claim.

But if you want a concrete example I've dealt with recently, there's
places where which registration you use is being defined by
guess-the-spec-text-we-should-have-and-see-what-sticks
(<https://github.com/slightlyoff/ServiceWorker/issues/356>), which makes
me seriously doubt the end result matches whatever Chrome has actually
implemented. Now I could go and reverse engineer the Chrome
implementation to see what it actually does and we could implement that
in Gecko, but this is a concrete example of where it's just not possible
that you can implement based on what the spec says, because the spec has
no idea what it's saying...

The people at Mozilla who have actually been actively implementing this
and dealing with this spec (which is not me) can give you more examples,
I'm sure.

-Boris

[Mounir Lamouri]

On Wed, 15 Oct 2014, at 12:48, Kenji Baheux wrote:
> + We semi-regularly reconcile the spec and our implementation. We have a
> defined process for that.

It sounds a bit scary to ship while still reconciling with the
specification on a regular basis. Are the bits that we intend to ship
actually stable?

> - The pass rate of the test suite in Firefox is low, although that’s
> mostly
> because some things are not implemented there yet.

Maybe it would be interesting to know which tests are failing for actual
interoperability issues and which are failing because Mozilla did not
catch up yet?

-- Mounir

[Alex Russell]

On Wednesday, October 15, 2014 6:35:19 AM UTC-7, Mounir Lamouri wrote:

On Wed, 15 Oct 2014, at 12:48, Kenji Baheux wrote:
> + We semi-regularly reconcile the spec and our implementation. We have a
> defined process for that.

It sounds a bit scary to ship while still reconciling with the
specification on a regular basis. Are the bits that we intend to ship
actually stable?

Yes. We're shipping registration (which has been settled for a long while), the onfetch event, and the upgrade progress. There might be areas where we can add improvements to them, but it's my belief that they're all going to be additive.

 

> - The pass rate of the test suite in Firefox is low, although that’s
> mostly
> because some things are not implemented there yet.

Maybe it would be interesting to know which tests are failing for actual
interoperability issues and which are failing because Mozilla did not
catch up yet?

It's a good point. I know Kenji started looking into it and I'll sync up with Dominic when TOK comes back online. 

[nsm.n...@gmail.com]

On Wednesday, October 15, 2014 6:35:19 AM UTC-7, Mounir Lamouri wrote:

Note that our ServiceWorker work is happening on the maple branch[1] and builds are available for all platforms from there.

[1]: https://treeherder.mozilla.org/ui/#/jobs?repo=maple

Nikhil

[Alex Russell]

Do you have a more direct pointer to working builds? I just tried a recent green build from the maple buildbots but it seemed corrupted on OSX.

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

[Daniel Bratell]

On Wed, 15 Oct 2014 03:48:41 +0200, Kenji Baheux <kenji...@chromium.org> wrote:

Notably, the Cache API as defined in the spec is not in the subset covered by this Intent. We intend to file a separate Intent once both the blink implementation and spec have stabilized.

[snip]

1. Reducing page load latency

For users who have previously visited a site, Service Workers can accelerate page loading. See this comparison of the user experience between No Service Worker and With Service Worker. How Service Workers can reduce latency is described in this overview. You can experience it yourself in the demo below.

Ok, so I don't know the details of ServiceWorker, but the performance (time to first render) improvements seem to come from using cached (possibly out of date) objects during page load. How will those objects be found without the Cache API?

Another thing I wonder about is memory usage, will resources in an optimal ServiceWorker be stored twice, once in the HTTP cache and once in the ServiceWorker?

/Daniel

[Alex Russell]

On Wed, Oct 15, 2014 at 12:54 PM, Daniel Bratell <bra...@opera.com> wrote:

On Wed, 15 Oct 2014 03:48:41 +0200, Kenji Baheux <kenji...@chromium.org> wrote:

Notably, the Cache API as defined in the spec is not in the subset covered by this Intent. We intend to file a separate Intent once both the blink implementation and spec have stabilized.

[snip]

1. Reducing page load latency

For users who have previously visited a site, Service Workers can accelerate page loading. See this comparison of the user experience between No Service Worker and With Service Worker. How Service Workers can reduce latency is described in this overview. You can experience it yourself in the demo below.

Ok, so I don't know the details of ServiceWorker, but the performance (time to first render) improvements seem to come from using cached (possibly out of date) objects during page load. How will those objects be found without the Cache API?

Polyfills exist that work for same-origin resources using IDB+Blob storage and we intend to send a separate intent-to-ship on the Cache bits of the API within the week; this is also targeted at M40, so they should come to developers as a package, this list willing.

 

Another thing I wonder about is memory usage, will resources in an optimal ServiceWorker be stored twice, once in the HTTP cache and once in the ServiceWorker?

It is possible to de-dupe at the disk level. Think of the SW cache and the HTTP cache as conceptually adding a reference to an object which isn't freed until both drop it.

Regards 

[Boris Zbarsky]

On 10/15/14, 8:30 AM, Boris Zbarsky wrote:
> The people at Mozilla who have actually been actively implementing this
> and dealing with this spec (which is not me) can give you more examples,
> I'm sure.

I talked to one of them briefly, and here were some concerns off the top
of his head:

1) "For registrations ([[Update]] and [[Install]]) the spec is pretty
unwieldy about ordering since it doesn't seem to use the queue a task
concept."

2) "I believe postMessage in ref to lifetime of the SW is not well
defined, because a SW may not be running when it gets postMessaged()"

3) "fetch() - the spec is still changing although not the API surface,
the way request & response streams work, and clone() was only just
updated 2 days ago. Issue 256 so i'm not sure how they are shipping
fetch interception."

My spidey-sense tingled a bit upon reading issue 256, if that API is in
the set that's proposed to be shipped. Which I think it is.

-Boris

[Alex Russell]

On Wed, Oct 15, 2014 at 1:11 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 10/15/14, 8:30 AM, Boris Zbarsky wrote:

The people at Mozilla who have actually been actively implementing this
and dealing with this spec (which is not me) can give you more examples,
I'm sure.

I talked to one of them briefly, and here were some concerns off the top of his head:

1)  "For registrations ([[Update]] and [[Install]]) the spec is pretty unwieldy about ordering since it doesn't seem to use the queue a task concept."

It's unclear how that would clarify things as the SW may live in a separate process. Junkee has added synchronization text which captures the essential spirit, and we're happy to iterate, but nothing about this seems problematic to developers.

 

2)  "I believe postMessage in ref to lifetime of the SW is not well defined, because a SW may not be running when it gets postMessaged()"

It will recieve onmessage as per usual. That can wake up the SW. That's not spec'd on purpose.

 

3)  "fetch() - the spec is still changing although not the API surface, the way request & response streams work, and clone() was only just updated 2 days ago.

clone() was the last of the late decisions, and my understanding is that we have broad agreement. It was _SPECIFICALLY_ decided to ameliorate sicking's concerns (which I still disagree with, but which we gave way on and produced a less-usable API as a result of). The rest of the streams interaction is hidden in our impl as we aren't exposing response streams. When there is consensus there, we will implement. What's moving forward in Chrome are the areas we have come to agreement on and believe are future-proofed against Streams API flapping.

 

  Issue 256 so i'm not sure how they are shipping fetch interception."

Issue 256 in the SW repo? That's not going anywhere. We've decided. Closed.

 

My spidey-sense tingled a bit upon reading issue 256, if that API is in the set that's proposed to be shipped.  Which I think it is.

-Boris

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

[Boris Zbarsky]

On 10/15/14, 4:48 PM, 'Alex Russell' via blink-dev wrote:
> It's unclear how that would clarify things as the SW may live in a
> separate process. Junkee has added synchronization text which captures
> the essential spirit, and we're happy to iterate, but nothing about this
> seems problematic to developers.

It's problematic for developers if different UAs end up with different
observable behavior. Again, I haven't looked at this in detail; just
passing on feedback I got.

> 2) "I believe postMessage in ref to lifetime of the SW is not well
> defined, because a SW may not be running when it gets postMessaged()"
>
> It will recieve onmessage as per usual. That can wake up the SW. That's
> not spec'd on purpose.

I'm not sure I follow. Again, is the web-page-observable behavior
specified clearly enough to implement?

> clone() was the last of the late decisions, and my understanding is that
> we have broad agreement.

Good to hear.

> The rest of the
> streams interaction is hidden in our impl as we aren't exposing response
> streams. When there is consensus there, we will implement. What's moving
> forward in Chrome are the areas we have come to agreement on and believe
> are future-proofed against Streams API flapping.

Also good to hear, thanks.

> Issue 256 in the SW repo?

Yes.

> That's not going anywhere. We've decided. Closed.

Just to make sure, the "we" includes someone outside Google, yes? ;)

Thanks for following up on this,
Boris

[Alex Russell]

On Wed, Oct 15, 2014 at 3:36 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 10/15/14, 4:48 PM, 'Alex Russell' via blink-dev wrote:

It's unclear how that would clarify things as the SW may live in a
separate process. Junkee has added synchronization text which captures
the essential spirit, and we're happy to iterate, but nothing about this
seems problematic to developers.

It's problematic for developers if different UAs end up with different observable behavior.  Again, I haven't looked at this in detail; just passing on feedback I got.

    2)  "I believe postMessage in ref to lifetime of the SW is not well
    defined, because a SW may not be running when it gets postMessaged()"

It will recieve onmessage as per usual. That can wake up the SW. That's
not spec'd on purpose.

I'm not sure I follow.  Again, is the web-page-observable behavior specified clearly enough to implement?

I believe it is, yes.

 

clone() was the last of the late decisions, and my understanding is that
we have broad agreement.

Good to hear.

The rest of the
streams interaction is hidden in our impl as we aren't exposing response
streams. When there is consensus there, we will implement. What's moving
forward in Chrome are the areas we have come to agreement on and believe
are future-proofed against Streams API flapping.

Also good to hear, thanks.

Issue 256 in the SW repo?

Yes.

That's not going anywhere. We've decided. Closed.

Just to make sure, the "we" includes someone outside Google, yes?  ;)

Yes.

[jung...@gmail.com]

2014년 10월 16일 목요일 오전 7시 36분 25초 UTC+9, Boris Zbarsky 님의 말:

On 10/15/14, 4:48 PM, 'Alex Russell' via blink-dev wrote:
> It's unclear how that would clarify things as the SW may live in a
> separate process. Junkee has added synchronization text which captures
> the essential spirit, and we're happy to iterate, but nothing about this
> seems problematic to developers.

It's problematic for developers if different UAs end up with different
observable behavior.  Again, I haven't looked at this in detail; just
passing on feedback I got.

I'd like to get another feedback on the latest version (with the updated synchronization text) from Nikhil and the implementers.

[Anne van Kesteren]

On Thu, Oct 16, 2014 at 2:14 AM, 'Alex Russell' via blink-dev
<blin...@chromium.org> wrote:
> On Wed, Oct 15, 2014 at 3:36 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>> On 10/15/14, 4:48 PM, 'Alex Russell' via blink-dev wrote:
>>> It will recieve onmessage as per usual. That can wake up the SW. That's
>>> not spec'd on purpose.
>>
>> I'm not sure I follow. Again, is the web-page-observable behavior
>> specified clearly enough to implement?
>
> I believe it is, yes.

No it's not. Not saying that postMessage() wakes up a service worker
is fine. But leaving it completely undefined what happens between
postMessage() and a message event arriving at the other end is not.
There's a huge difference.


--
https://annevankesteren.nl/

[Daniel Bratell]

On Wed, 15 Oct 2014 22:00:13 +0200, Alex Russell <sligh...@google.com> wrote:

On Wed, Oct 15, 2014 at 12:54 PM, Daniel Bratell <bra...@opera.com> wrote:

On Wed, 15 Oct 2014 03:48:41 +0200, Kenji Baheux <kenji...@chromium.org> wrote:

Notably, the Cache API as defined in the spec is not in the subset covered by this Intent. We intend to file a separate Intent once both the blink implementation and spec have stabilized.

[snip]

1. Reducing page load latency

For users who have previously visited a site, Service Workers can accelerate page loading. See this comparison of the user experience between No Service Worker and With Service Worker. How Service Workers can reduce latency is described in this overview. You can experience it yourself in the demo below.

Ok, so I don't know the details of ServiceWorker, but the performance (time to first render) improvements seem to come from using cached (possibly out of date) objects during page load. How will those objects be found without the Cache API?

Polyfills exist that work for same-origin resources using IDB+Blob storage and we intend to send a separate intent-to-ship on the Cache bits of the API within the week; this is also targeted at M40, so they should come to developers as a package, this list willing.

Basically until the Cache API comes, a ServiceWorker has to implement its own cache using whatever tools seem useful. So to get any performance improvements the resources must be at least double stored (disk cache and ServiceWorker), but it could easily be even more copies if the ServiceWorker also keeps in-RAM copies or passes large strings around.

If the only way to make this efficient is to use the Cache API and that is coming in a few days, why not just wait until both pieces are finished?

 

Another thing I wonder about is memory usage, will resources in an optimal ServiceWorker be stored twice, once in the HTTP cache and once in the ServiceWorker?

It is possible to de-dupe at the disk level. Think of the SW cache and the HTTP cache as conceptually adding a reference to an object which isn't freed until both drop it.

Quite a lot of things are possible, but for this thread I'm interested in what the code that is listed for shipping will actually do. I think it would be best to wait for the Cache API too so that there is no shipped version that will promote patterns that will be harmful to the browser (except for quick demos). It would be so easy for a page author to store things in Blob objects not realizing that you are wasting RAM like mad. Actually, I think most sites would love to waste browser memory if it was needed to make their site fast so with the lack of options, that seems more or less inevitable.

/Daniel

[Jake Archibald]

On 16 Oct 2014 09:07, "Daniel Bratell" <bra...@opera.com> wrote:
>
> On Wed, 15 Oct 2014 22:00:13 +0200, Alex Russell <sligh...@google.com> wrote:
>
>> On Wed, Oct 15, 2014 at 12:54 PM, Daniel Bratell <bra...@opera.com> wrote:
>>>
>>> On Wed, 15 Oct 2014 03:48:41 +0200, Kenji Baheux <kenji...@chromium.org> wrote:
>>>
>>>> Notably, the Cache API as defined in the spec is not in the subset covered by this Intent. We intend to file a separate Intent once both the blink implementation and spec have stabilized.
>>>
>>>
>>> [snip]
>>>
>>>
>>>>
>>>> 1. Reducing page load latency
>>>>
>>>> For users who have previously visited a site, Service Workers can accelerate page loading. See this comparison of the user experience between No Service Worker and With Service Worker. How Service Workers can reduce latency is described in this overview. You can experience it yourself in the demo below.
>>>
>>>
>>> Ok, so I don't know the details of ServiceWorker, but the performance (time to first render) improvements seem to come from using cached (possibly out of date) objects during page load. How will those objects be found without the Cache API?
>>
>>
>> Polyfills exist that work for same-origin resources using IDB+Blob storage and we intend to send a separate intent-to-ship on the Cache bits of the API within the week; this is also targeted at M40, so they should come to developers as a package, this list willing.
>
>
> Basically until the Cache API comes, a ServiceWorker has to implement its own cache using whatever tools seem useful. So to get any performance improvements the resources must be at least double stored

Can you explain this a bit more? The trained-to-thrill demo uses IDB for the cache. Items are stored in IDB as blobs. The same items may end up in the normal browser cache, but they can disappear from there without leaving IDB.

The benefits are huge, even with the polyfill cache. A native implementation gives us room for optimisation, and optimisation will continue for years afterwards, as with every browser feature. I don't think we need to wait until perfection until shipping, else no one would have managed to release "a browser".

[Daniel Bratell]

On Thu, 16 Oct 2014 11:38:27 +0200, Jake Archibald <jakear...@google.com> wrote:

On 16 Oct 2014 09:07, "Daniel Bratell" <bra...@opera.com> wrote:
 >> Basically until the Cache API comes, a ServiceWorker has to implement its own cache using whatever tools seem useful. So to get any performance improvements the resources must be at least double stored

Can you explain this a bit more? The trained-to-thrill demo uses IDB for the cache. Items are stored in IDB as blobs. The same items may end up in the normal browser cache, but they can disappear from there without leaving IDB.

Basically my concern is that it will be double stored (at least; I don't know how many internal copies in RAM a ServiceWorker will create). We will have two of things where one should be enough.

The benefits are huge, even with the polyfill cache. A native implementation gives us room for optimisation, and optimisation will continue for years afterwards, as with every browser feature. I don't think we need to wait until perfection until shipping, else no one would have managed to release "a browser".

The benefits are huge when used correctly, but if the initial implementation more or less forces it to be used incorrectly (I consider anything that double stores data incorrect) it could form the pattern for the future. Now Alex Russel wrote that the Cache API should be ready to ship within a week, so why not wait until then?

It is still available behind a flag for testing, demos, experimenting and development right?

/Daniel

[Rick Byers]

I just want to say I support shipping this subset.

There's obviously still non-trivial compat risk, but more than almost any other feature there is real risk to the platform with every release that goes out without really pushing the web forward here.

Its a tough trade-off, and I won't pretend to be able to judge what the right balance is myself.  But there's no one I would trust more to take all the feedback and strike a good (but aggressive) balance for what's best for the web than Alex and the team. I'm impressed by the urgency and energy they've brought to this problem. If we weren't uncomfortable about the risks, then it would be a sign we're not being aggressive enough.

Rick

[PhistucK]

I completely agree with you. Both of them should be shipped together. It does not make any sense to promote the first without the second.

☆PhistucK

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

[Dominic Cooney]

On Fri, Oct 17, 2014 at 8:05 AM, PhistucK <phis...@gmail.com> wrote:

I completely agree with you. Both of them should be shipped together. It does not make any sense to promote the first without the second.

☆PhistucK

On Thu, Oct 16, 2014 at 5:03 PM, Daniel Bratell <bra...@opera.com> wrote:

On Thu, 16 Oct 2014 11:38:27 +0200, Jake Archibald <jakear...@google.com> wrote:

On 16 Oct 2014 09:07, "Daniel Bratell" <bra...@opera.com> wrote:
 >> Basically until the Cache API comes, a ServiceWorker has to implement its own cache using whatever tools seem useful. So to get any performance improvements the resources must be at least double stored

Can you explain this a bit more? The trained-to-thrill demo uses IDB for the cache. Items are stored in IDB as blobs. The same items may end up in the normal browser cache, but they can disappear from there without leaving IDB.

Basically my concern is that it will be double stored (at least; I don't know how many internal copies in RAM a ServiceWorker will create). We will have two of things where one should be enough.

I wasn't happy about this situation either. Of course, multiple representations of resources exist in RAM at various times, even without Service Worker, and the Service Worker author has control over how long they hold onto memory, so I'm more concerned about disk consumption than RAM. Looking at my phone, my Chrome cache is 245 MB. If Service Workers are successful we could be talking about hundreds of megabytes here. On the other hand, the HTTP cache is ephemeral, and the author has control over not putting things into the HTTP cache using cache headers. So I'm reluctantly persuaded that this situation is OK. In my gut, I trust web developers care about efficiency and when the native Cache is available they'll be racing to adopt it. Separately, there might be cases where Blobs end up double-stored in Indexed DB and the HTTP cache even today. Someone could investigate de-duping them which would also ameliorate this issue and may benefit some other use cases too.

[Jochen Eisinger]

Did you get feedback on the latest version you could share with us?

thanks

-jochen

 

[Jochen Eisinger]

Anne, do I understand you correctly that you suggest to add some algorithm to the spec that wakes up the SW before delivering the event?

best

-jochen

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Mon, Oct 20, 2014 at 4:13 PM, Jochen Eisinger <joc...@chromium.org> wrote:
> Anne, do I understand you correctly that you suggest to add some algorithm
> to the spec that wakes up the SW before delivering the event?

Yes, the specification is lacking that algorithm and the algorithm
that describes what needs to be done when a service worker is
terminated (for whatever reason). And with that the various concept
that go along with it, e.g. defining what the environment settings
objects (see HTML) looks like for a service worker.

I have submitted a whole bunch of issues already with regards to
defining things like this, though there's often lag of weeks to months
before they get some attention requiring me to read up on everything
again. It's somewhat painful for something that's supposed to be
actively developed.


--
https://annevankesteren.nl/

[Alex Russell]

On Thu, Oct 16, 2014 at 7:45 PM, Dominic Cooney <domi...@chromium.org> wrote:

On Fri, Oct 17, 2014 at 8:05 AM, PhistucK <phis...@gmail.com> wrote:

I completely agree with you. Both of them should be shipped together. It does not make any sense to promote the first without the second.

☆PhistucK

On Thu, Oct 16, 2014 at 5:03 PM, Daniel Bratell <bra...@opera.com> wrote:

On Thu, 16 Oct 2014 11:38:27 +0200, Jake Archibald <jakear...@google.com> wrote:

On 16 Oct 2014 09:07, "Daniel Bratell" <bra...@opera.com> wrote:
 >> Basically until the Cache API comes, a ServiceWorker has to implement its own cache using whatever tools seem useful. So to get any performance improvements the resources must be at least double stored

Can you explain this a bit more? The trained-to-thrill demo uses IDB for the cache. Items are stored in IDB as blobs. The same items may end up in the normal browser cache, but they can disappear from there without leaving IDB.

Basically my concern is that it will be double stored (at least; I don't know how many internal copies in RAM a ServiceWorker will create). We will have two of things where one should be enough.

I wasn't happy about this situation either. Of course, multiple representations of resources exist in RAM at various times, even without Service Worker, and the Service Worker author has control over how long they hold onto memory, so I'm more concerned about disk consumption than RAM. Looking at my phone, my Chrome cache is 245 MB. If Service Workers are successful we could be talking about hundreds of megabytes here.

I think it's important to note that:

• These sites don't exist today. Even unprecedentedly-fast uptake is likely to give us several versions in which to launch the Cache API and implement de-duplication.
• Sites using a Cache Polyfill will begin using the real Cache as soon as we ship it (which, again, should also be in the first version of Chrome to include SW's, see below).
• We plan on scheduling work to do on-disk de-duplication of resources between the HTTP and SW caches, so as usage ramps up, we're going to be improving this story.
• We're giving users much better control over resource usage in M40 with a revamped Site Settings system.
• Giving developers power means giving developers power. Hand-wringing about what they might do with it isn't actionable.
• This is already happens with AppCache and Service Workers are likely to do better.  To understand this, it's helpful to understand how contorted AppCache sites wind up being: because there's only one cache in an AppCache app, sites are faced with the (terrible) choice to either try to store resources in IDB or to try to pile everything into a single cache manifest and deal with many versions in the wild when even the smallest change occurs. AppCache-using sites mostly opt for the former, making the terrible counter-factual for Service Worker's merely the status quo. Holding up SW's for a Cache API is nonsensical.

Lastly, even if you want the Cache API in for the initial release of SW's, that's a reason to +1 the Cache API Intent-to-Ship that will be forthcoming shortly, not a reason to withhold a +1 in this thread.

On the other hand, the HTTP cache is ephemeral, and the author has control over not putting things into the HTTP cache using cache headers. So I'm reluctantly persuaded that this situation is OK. In my gut, I trust web developers care about efficiency and when the native Cache is available they'll be racing to adopt it.

I think this is absolutely going to be the case. The polyfills will largely make this transparent.

[jung...@gmail.com]

2014년 10월 20일 월요일 오후 11시 4분 29초 UTC+9, Jochen Eisinger 님의 말:

For this particular instance about the synchronization of multiple registration algorithm steps running in parallel, neither a feedback nor a further issue has been filed. Here are the related github tickets that I'd like to close upon some feedback:

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

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

thanks

-jochen

 

[al...@microsoft.com]

I'm with the IE Platform team at Microsoft. We believe that the concepts and scenarios for Service Workers make sense. However, because we have not built a prototype for it yet, our evaluation of the current spec is limited in depth. But here are some issues we currently see that might be worrisome for Chrome to ship Service Workers before the spec and another implementation settles.

#1 Flexibility on Changes

How flexible would the API be after Chrome ships this feature? Would we be able to change any part of it, or will this mean that the current API will be locked in? How will Google be sure that this API can become interoperable given that Firefox is failing tests and Chrome only implements part of the spec? Would Google be willing to change behaviors and/or APIs in the future if an interop issue arose because sites assumed Chrome's behaviors and guarantees would be in all browsers? Preferably, we would like to see two complete implementations before the APIs are locked in. By doing this we would gain a firmer grasp of any issues with the API which would allow us to make changes to it without taking a big interop hit.

#2 Lack of Cache API

As mentioned by others, we're a little concerned that there is no Cache API currently implemented as part of Canary. Because of that it has not received any public testing. Is there a plan to port this to Canary and have it be experimental, or is it going to ship directly with the rest of the Service Workers API?

#3 Consistency of Behavior across User Agents

There are a few behaviors that are not well defined in the Service Workers W3C spec such as when a service worker would be active or not. There were conversations around the idea that the user agent is ultimately responsible for deciding when Service Workers are started and shut down. This could cause interoperability issues in that one user agent may decide to have a Service Worker active while another user agent decides to not have it be active. Depending on how the Service Worker is used this could result in an inconsistent experience. Moreover, if the current Chrome implementation implicitly guarantees certain startup/shutdown behavior then following implementations may be forced to also provide those same guarantees. Specifically, there could be a major issue if a user agent decides that a Service Worker never runs when the site is trying to employ Service Workers as a dynamic caching mechanism. For example, suppose you were responding to all requests with something in the cache if it exists, if not, you cache it for next time. The dynamic cache would not be able to be built if the Service Worker was not running when a new request was made. This would consequently invalidate the dynamic caching scenario.

Additionally, looking to the future of Service Workers, we feel that web developers will enhance their sites and web apps and not be able to provide equivalent fallbacks when Service Workers do not run. That means if the user agent decides to not run a Service Worker, the experience could feel impaired. The thread RE: Push API and Service Workers [1] is an example of where the Service Worker activation inconsistency might be an issue. There would be interop issues in the app processing model since individual UAs are responsible for determining when Service Workers run.

We would like to see this aspect of Service Workers firmed up in the W3C spec so that we can deliver a more predictable experience across different user agents.

Having said that, we are okay with Blink shipping this provided you remain flexible with changes should the need arise.

Thank you,

Ali

[1] http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0152.html

[Alex Russell]

Hi Ali,

Thanks for chiming in here. It's great to see MSFT engaging publicly.

On Tue, Oct 21, 2014 at 10:45 AM, <al...@microsoft.com> wrote:

I'm with the IE Platform team at Microsoft. We believe that the concepts and scenarios for Service Workers make sense. However, because we have not built a prototype for it yet, our evaluation of the current spec is limited in depth. But here are some issues we currently see that might be worrisome for Chrome to ship Service Workers before the spec and another implementation settles.

#1 Flexibility on Changes

How flexible would the API be after Chrome ships this feature?

It's going to depend on the area under discussion. We welcome your feedback in GitHub (and always have). Are there specific areas you're looking to help drive changes to?

In general, the bits we're proposing to ship now are the pieces of the API that we think are most solid. We've left areas like Steams out of our MVP as they don't seem settled yet and have carefully designed around them.

 

Would we be able to change any part of it, or will this mean that the current API will be locked in? How will Google be sure that this API can become interoperable given that Firefox is failing tests and Chrome only implements part of the spec?

We have a bias towards the part of the spec that have the widest consensus and solve important use-cases. Kenji has been looking into the Mozilla implementation pass rates, and there appear to be some issues that aren't related to Chrome implementation fidelity.

 

Would Google be willing to change behaviors and/or APIs in the future if an interop issue arose because sites assumed Chrome's behaviors and guarantees would be in all browsers?

As you are aware, the best way to avoid a world where sites come to depend on a vendor's specific behavior is to create a situation in which multiple implementations exist. That's a ball that's, to some extent, in your court.

 

Preferably, we would like to see two complete implementations before the APIs are locked in.

We view Service Workers as a high-priority feature. If you'd like to implement and provide feedback, there's a 12 week window post our branch point before this feature will go to Chrome Stable (and some time post that before sites start to actively use the feature). You have a window, but it is closing, and as a rule, we will not hold our train because others haven't already left the station.

 

By doing this we would gain a firmer grasp of any issues with the API which would allow us to make changes to it without taking a big interop hit.

We welcome your concrete feedback in the github repo.

 

#2 Lack of Cache API

As mentioned by others, we're a little concerned that there is no Cache API currently implemented as part of Canary. Because of that it has not received any public testing. Is there a plan to port this to Canary and have it be experimental, or is it going to ship directly with the rest of the Service Workers API?

As previously covered, there's a forthcoming Intent-to-Ship, but we believe we've demonstrated huge value without the Cache API.

 

#3 Consistency of Behavior across User Agents

There are a few behaviors that are not well defined in the Service Workers W3C spec such as when a service worker would be active or not.

As you know, this is intentionally left to implementations to enable them to manage CPU, memory, and network resources when under pressure. Pre-emptive specification of these aspects is harmful to our ability to do the right thing for users and, at a system level, would be a poor contract to enter into with developers (if we can't keep it).

Chrome's implementation aggressively kills SW's to keep developers from relying on global state. We can discuss loosening those restrictions at some point in the future when we believe we have more understanding, but we're "failing closed" in ways that preserve our ability to change this policy in the future.

 

There were conversations around the idea that the user agent is ultimately responsible for deciding when Service Workers are started and shut down. This could cause interoperability issues in that one user agent may decide to have a Service Worker active while another user agent decides to not have it be active. Depending on how the Service Worker is used this could result in an inconsistent experience. Moreover, if the current Chrome implementation implicitly guarantees certain startup/shutdown behavior then following implementations may be forced to also provide those same guarantees. Specifically, there could be a major issue if a user agent decides that a Service Worker never runs when the site is trying to employ Service Workers as a dynamic caching mechanism. For example, suppose you were responding to all requests with something in the cache if it exists, if not, you cache it for next time. The dynamic cache would not be able to be built if the Service Worker was not running when a new request was made. This would consequently invalidate the dynamic caching scenario.

Additionally, looking to the future of Service Workers, we feel that web developers will enhance their sites and web apps and not be able to provide equivalent fallbacks when Service Workers do not run.

This, as you know, is part of the core model. Web developers understand progressive enhancement and already work to ensure that their content works across multiple environments. The lack of SW-supporting UA's guarantees that this adaptation will be required of sites for the foreseeable future.

 

That means if the user agent decides to not run a Service Worker, the experience could feel impaired.

This is, again, by design.

 

The thread RE: Push API and Service Workers [1] is an example of where the Service Worker activation inconsistency might be an issue. There would be interop issues in the app processing model since individual UAs are responsible for determining when Service Workers run.

We would like to see this aspect of Service Workers firmed up in the W3C spec so that we can deliver a more predictable experience across different user agents.

Having said that, we are okay with Blink shipping this provided you remain flexible with changes should the need arise.

Thank you,

Ali

[1] http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0152.html

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

[Kenji Baheux]

> - The pass rate of the test suite in Firefox is low, although that’s
> mostly
> because some things are not implemented there yet.

Maybe it would be interesting to know which tests are failing for actual
interoperability issues and which are failing because Mozilla did not
catch up yet?

It's a good point. I know Kenji started looking into it and I'll sync up with Dominic when TOK comes back online. 

I ran our Blink Service Worker test suite in a recent maple build of Firefox (maple 35.0a1 2014-10-06 Mac OS X).

Configuration:

• Mac OS X 10.9.3

• dom.messageChannel.enabled = true

• dom.serviceWorkers.enabled = true

• dom.serviceWorkers.testing.enabled = true

See this spreadsheet for the run down.

1. It turns out that 78% of our tests don't have a chance to exert any of their assertions on Firefox.

This is because we rely on specific lifecycle events to kick our assertions.

With Firefox, most of our tests are waiting forever after these events.

Nikhil confirmed that Firefox's implementation isn't spec compliant at this moment.

A patch is on its way and I offered to re-run the tests. In the meantime, I'll see if I can hack around this issue and hit more assertions.

2. The second speed bump (6%) is about what appears to be an issue with window.postMessage.

The console output "argument 3 can't be converted to a sequence" errors.

I haven't fully grok it all. If you have any insights let me know.

Note: These tests are using MessageChannel which is also behind an experimental flag in Firefox.

3. Then, for the tests that do run, we have 4 tests for which we are in a disagreement with Firefox's implementation

I believe that our tests are compliant with the spec:

For controller-on-reload.html, I believe that the test is failing on Firefox because the base URI of the document is ignored which results in a “SW script not found error”.

For getRegistration.html, the assertion that fails is about checking that getRegistration gives you back the same ServiceWorkerRegistration object. See the relevant github issue.

For registration.html, I believe that Blink is following the spec:

SW script redirects => SecurityError

SW script with the wrong mime-type => SecurityError

inexistent SW script => NetworkError

For registration-service-worker-attributes.html, Blink is following the spec. The assertions that fail are testing the scriptURL attribute of a Service Worker as it goes through the different state of a registration. Firefox’s implementation is based on an old version of the spec where scriptURL used to be URL.

Changing scriptURL to url to accommodate FF’s implementation leads us to the event issue noted above (the test is blocked because it's not observing the updatefound event it relies on to move forward)

• 2/3 of the initial assertions PASS (the assertions before the wait_for_update choke point).
• Interestingly, the one that fails is about checking that the ServiceWorkerRegistration object’s active SW is null. In FF’s implementation, I’m observing an installing SW (expected) as well as an active SW whose state is set to “installing”. I believe that you can’t have an installing SW and an active SW with just one on-going registration (and no previous registration). Also, an active SW with an “installing” state is incorrect per spec. See http://goo.gl/HUh3PT

4. Finally, 2 tests are green (all assertions PASS).

One set of test to check that rejections are DOMExceptions, and another set of test about unregistering SW (i.e. duplicate unregister calls should not fail, unregistering should resolve with true).

------------------------

I also did the other way around by running Firefox's service worker tests in Chrome.

Here is the run down.

Summary:

• Blink’s SW implementation is passing all the relevant tests.

• There are some assertions that rely on obsolete APIs which are hard to fix (4 assertions out of ~45)

• There are a couple of tests that don’t apply to Blink either because of Firefox specific code/env (2 instances) or because we haven’t implemented a particular method yet (also 2 instances)

• There is one test for which I ran into a wall (it seems to require some specific environment that I can’t reproduce locally).

I hope this helps, let me know.

[Kenji Baheux]

Sorry wrong link for the second run down.

Here is the correct version:

I also did the other way around by running Firefox's service worker tests in Chrome.
Here is the run down.

2014年10月22日水曜日 15時03分04秒 UTC+9 Kenji Baheux:

[PhistucK]

Can you, please, make the document public? I currently get a "request a permission" screen.

Thank you!

☆PhistucK

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

[Boris Zbarsky]

On 10/22/14, 2:03 AM, Kenji Baheux wrote:
> *2. The second speed bump (6%) is about what appears to be an issue with
> window.postMessage.*

>
> The console output "argument 3 can't be converted to a sequence" errors.
>
> I haven't fully grok it all. If you have any insights let me know.

I looked at fetch-canvas-tainting.html.

The test is doing:

frame.contentWindow.postMessage({},
[channel.port2],
host_info['HTTP_ORIGIN']);

but spec for postMessage is:

void postMessage(any message, DOMString targetOrigin, optional
sequence<Transferable> transfer);

So the test is trying to pass an array for the targetOrigin (which
dutifully gets converted to some random string) and trying to pass a
string for the transferables sequence. A string is not a sequence
(because it's not an object at all), so you get the exception.

I have no idea why this works in Blink; even if we accept that whatever
Blink does for sequences is totally unrelated to what the Web IDL spec
says to do, I'd think that the bogus origin string should prevent the
message from being delivered...

> <https://docs.google.com/a/google.com/spreadsheets/d/1HT5hLzgMLXfULiURvPLGfinFxtSPK_aVoSl4Uj22OI0/edit#gid=0>

Not accessible for me, fwiw.

-Boris

[Dominic Cooney]

On Wed, Oct 22, 2014 at 3:34 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 10/22/14, 2:03 AM, Kenji Baheux wrote:

*2. The second speed bump (6%) is about what appears to be an issue with
window.postMessage.*

The console output "argument 3 can't be converted to a sequence" errors.

I haven't fully grok it all. If you have any insights let me know.

I looked at fetch-canvas-tainting.html.

The test is doing:

  frame.contentWindow.postMessage({},
                                  [channel.port2],
                                  host_info['HTTP_ORIGIN']);

That looks like a bug in the test, I have posted https://codereview.chromium.org/651603004/ Horo, could you PTAL? Maybe the test can be simplified if it passed with this error in it?

Bashi, could you investigate why the original code didn't throw a type error?

[PhistucK]

Legacy non standard WebKit behavior. :(

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/core/v8/custom/V8WindowCustom.cpp&rcl=1413836064&l=257

    // This function has variable arguments and can be:
    // Per current spec:
    //   postMessage(message, targetOrigin)
    //   postMessage(message, targetOrigin, {sequence of transferrables})
    // Legacy non-standard implementations in webkit allowed:
    //   postMessage(message, {sequence of transferrables}, targetOrigin);

This calls for a use counter, if one does not exist yet and a removal intent. :(

☆PhistucK

[Sigbjorn Finne]

This compat issue came up some time ago; see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13967

Adding a use counter sounds like a sensible next step; could you file a bug?

--sigbjorn

Den 10/22/2014 09:10, PhistucK skreiv:
> Legacy non standard WebKit behavior. :(
>
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/core/v8/custom/V8WindowCustom.cpp&rcl=1413836064&l=257
>
> // This function has variable arguments and can be:
> // Per current spec:
> // postMessage(message, targetOrigin)
> // postMessage(message, targetOrigin, {sequence of transferrables})
> // Legacy non-standard implementations in webkit allowed:
> // postMessage(message, {sequence of transferrables}, targetOrigin);
>
>
> This calls for a use counter, if one does not exist yet and a removal
> intent. :(
>
>

> ☆*PhistucK*

>
> On Wed, Oct 22, 2014 at 9:59 AM, Dominic Cooney <domi...@chromium.org
> <mailto:domi...@chromium.org>> wrote:
>
>
>
> On Wed, Oct 22, 2014 at 3:34 PM, Boris Zbarsky <bzba...@mit.edu
> <mailto:bzba...@mit.edu>> wrote:
>
> On 10/22/14, 2:03 AM, Kenji Baheux wrote:
>
> *2. The second speed bump (6%) is about what appears to be
> an issue with
> window.postMessage.*
>
> The console output "argument 3 can't be converted to a
> sequence" errors.
>
> I haven't fully grok it all. If you have any insights let me
> know.
>
>
> I looked at fetch-canvas-tainting.html.
>
> The test is doing:
>

> frame.contentWindow.__postMessage({},

> [channel.port2],
> host_info['HTTP_ORIGIN']);
>
>
> That looks like a bug in the test, I have posted
> https://codereview.chromium.org/651603004/ Horo, could you PTAL?
> Maybe the test can be simplified if it passed with this error in it?
>
> Bashi, could you investigate why the original code didn't throw a
> type error?
>
> but spec for postMessage is:
>
> void postMessage(any message, DOMString targetOrigin,
> optional sequence<Transferable> transfer);
>
> So the test is trying to pass an array for the targetOrigin
> (which dutifully gets converted to some random string) and
> trying to pass a string for the transferables sequence. A
> string is not a sequence (because it's not an object at all), so
> you get the exception.
>
> I have no idea why this works in Blink; even if we accept that
> whatever Blink does for sequences is totally unrelated to what
> the Web IDL spec says to do, I'd think that the bogus origin
> string should prevent the message from being delivered...
>

> <https://docs.google.com/a/__google.com/spreadsheets/d/__1HT5hLzgMLXfULiURvPLGfinFxtSPK___aVoSl4Uj22OI0/edit#gid=0

> <https://docs.google.com/a/google.com/spreadsheets/d/1HT5hLzgMLXfULiURvPLGfinFxtSPK_aVoSl4Uj22OI0/edit#gid=0>>
>
>
> Not accessible for me, fwiw.
>
> -Boris
>
>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

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

> <mailto:blink-dev+...@chromium.org>.

[Kenji Baheux]

Sorry for the wrong link.

I thought I posted an errata but let me try again:

Sorry wrong link for the second run down.

Here is the correct version:

I also did the other way around by running Firefox's service worker tests in Chrome.
Here is the run down.

[PhistucK]

Still needs a permission.

☆PhistucK

[PhistucK]

Sure. Here you go.

crbug.com/425896

Thank you!

☆PhistucK

    send an email to blink-dev+unsubscribe@chromium.org
    <mailto:blink-dev+unsubscribe@chromium.org>.

To unsubscribe from this group and stop receiving emails from it, send

an email to blink-dev+unsubscribe@chromium.org
<mailto:blink-dev+unsubscribe@chromium.org>.

[Kenji Baheux]

slim fingers version of the link

Hopefully this time it's the right one.

[PhistucK]

That works - thank you!

☆PhistucK

[Boris Zbarsky]

On 10/22/14, 3:31 AM, Kenji Baheux wrote:
> slim fingers version of the link

> <https://docs.google.com/spreadsheets/d/172vcB6q_o8_en4O4OyyvpUZfvHY0c5EEZoUK-zU1qPQ/edit?usp=sharing>

>
> Hopefully this time it's the right one.

Thanks.

The test_installation_simple.html test depends at least on running with
a proxy that maps the hostnames in
http://mxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt#80
to the IP your HTTP server.

It also sets preferences, but I assume you just took that part out, right?

-Boris

[Eric Seidel]

It would appear that ServiceWorker includes Fetch then?
http://blink.lc/blink/tree/Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl#n42
and fetch() is not yet being exposed to the main Window.

It's a lot to ship at once.

It looks like FF's bug stalled out in April of this year.
I don't see any activity from WebKit:
https://bugs.webkit.org/buglist.cgi?quicksearch=serviceworker
I'm glad to hear that Microsoft is supportive of the idea.

The risk is high that we'll end up needing to support a
spec-incompatible implementation.

However I definitely see this as a huge step forward for the web.

> - The pass rate of the test suite in Firefox is low, although that’s mostly
> because some things are not implemented there yet.
>

[Nikhil Marathe]

On Wed, Oct 22, 2014 at 4:00 PM, 'Eric Seidel' via blink-dev <blin...@chromium.org> wrote:

It would appear that ServiceWorker includes Fetch then?
http://blink.lc/blink/tree/Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl#n42
and fetch() is not yet being exposed to the main Window.

It's a lot to ship at once.

It looks like FF's bug stalled out in April of this year.

Which bug has been stalled for Firefox?

Nikhil

[Eric Seidel]

https://bugzilla.mozilla.org/show_bug.cgi?id=903441 was the one I saw
from the original email. However I now see it's a meta bug, and
likely not updated due to activity on other bugs?

[Anne van Kesteren]

On Thu, Oct 23, 2014 at 1:00 AM, 'Eric Seidel' via blink-dev
<blin...@chromium.org> wrote:
> and fetch() is not yet being exposed to the main Window.

It would be nice to know if fetch() *can* be exposed there before
proceeding. Otherwise we might need to consider a different type of
design.


--
https://annevankesteren.nl/

[Kenji Baheux]

It also sets preferences, but I assume you just took that part out, right?

Confirming that I took the SpecialPowers calls out and forced the preferences manually.

Thanks to your explanation, I managed to get it working!

I've updated the spreadsheet:

• 1 test is about checking that non-https registrations fail but the implementation is specific to Firefox (turns off the dom.serviceworker.testing.enabled pref temporarily). However, we do have our own version of that test.
• 1 test appears to be non spec compliant. I left a comment with more details.
• 1 test is failing

So, in short we need to fix one bug to be all green on Firefox's ServiceWorker tests :)

--
Kenji BAHEUX

Product Manager - Chrome

Google Japan

[Jochen Eisinger]

Do you have a specific concern why this might not work?

[Anne van Kesteren]

On Thu, Oct 23, 2014 at 11:26 AM, Jochen Eisinger <joc...@chromium.org> wrote:
> Do you have a specific concern why this might not work?

Exposing new identifiers in the global scope is hairy.

<p id=fetch><script>fetch.innerHTML = "wtf"</script>


--
https://annevankesteren.nl/

[Kenji Baheux]

We've checked for that against our index and found the number to be insignificantly low.

2014年10月23日木曜日、Anne van Kesteren<ann...@annevk.nl>さんは書きました:

[Dimitri Glazkov]

Summary

The API owners met yesterday, October 22, 2014 to discuss the intent to ship Service Workers. We've decided to ship Service Workers under the guideline #4.

Compatibility risk

Compatibility risk is one of the most important decision criteria for enabling new web platform features by default. This section discusses the compatibility risk factors of shipping Service Workers at this time:

• Other vendors shipping compatible implementations.  Currently no other vendors are shipping compatible implementations of Service Workers.

• Mozilla has actively worked to co-design the feature and are currently implementing Service Workers behind a runtime flag. We are investigating the differences between test pass rates and are working towards sharing tests. Based on these discussions, Mozilla appears to be on track to ship a compatible implementation at some point in the future.

• A mature specification in the relevant standards body.  This feature has a spec under development by the W3C WebApps working group and the latest draft is under active development.

• The core Service Workers specification was first published as a working draft in May 2014 and is the result of years of design discussion and the experience of developers who built websites using previous web technologies (notably HTML 5 AppCache).

• We anticipate an updated Working Draft will be published by the Web Apps WG in the coming months.

• Positive signals from other browser vendors.

• Microsoft has commented publicly in our intent-to-ship thread, noting that:
       "...we are okay with Blink shipping this provided you remain flexible with
  

•       changes should the need arise."
  

• This implies that they have significant feedback to share but have not provided it yet. This is a risk. It is unclear that Microsoft will ship a compatible implementation in the near future, but it's worth noting that this is the first feature which they have publicly engaged one of our Intent-to-Ship's about.

• Apple has been silent about Service Workers thus far. This creates the risk that Apple will not ship a compatible implementation in the near future.

• A small API footprint.  Service Workers has a fairly large API footprint when viewed in terms of the number of new properties, functions, and number of implied dependencies. However, many of these features have been broken out (e.g., Fetch) and shipped independently (e.g., Promises). The API surface area added to documents is small, but behind this new entry point, Service Workers exposes a rich new Worker context for interacting with the network.

Controversy

The conceptual model of Service Workers is well established in the web platform because most browser engines already use this model internally to implement existing HTML features, such as AppCache. However, Service Workers expose these powerful tools to web developers, which raise some issues that browser vendors have not needed to resolve in their implementations of caching and existing offline tech (e.g. AppCache).

• Legacy multi-user hosting scenarios. Some potential adopters have worried that sites which serve SSL content for multiple users (e.g. https://university.example.com/~username) might find themselves astonished by Service Workers. As a result, a late decision has been taken to require opt-in to Service Worker behavior via HTTP Header which, it is posited, is a feature much more likely to be under administrative control.

• Streams API integration. The W3C Streams API has continued to change in large and small ways throughout the process of developing the Service Worker specification. Nearly all participants in the spec process agree that the body of a Response object is conceptually a stream, but until the API for Streams settles down, we're only going to ship a set of methods that enable consumption of the stream as a specific deserialized type (e.g., JSON or plain text in UTF-8 format) and cloning of the stream. It is thought that by not exposing response.body in the interim, this largely future-proof's the subset we will ship from potential changes to the Streams API.

• Generality of registration mechanism. There has been active debate about how general the registration mechanism for SW's are and if they need to be further generalized to divorce them from the navigation scope which they control. The data supporting those arguing for a change does not appear strong and a change at this late date would cause havoc in the spec. It's therefore unlikely that a change will be made, but driving to consensus on this issue has proven tricky.

Implementation experience

These controversies add risk to shipping Service Workers for two reasons:

1. Different browser vendors might ship incompatible implementations that take different positions on these topics; and

2. Service Workers might take a position on these topics that isn't what web developers want.

To help reduce the first type of risk, we've been in active discussions with other browser vendors about Service Workers over years inside and outside the W3C. Spec editors and input have come from diverse places (Mozilla, Samsung, etc.) and multiple in-face meetings have driven consensus on difficult topics. These topics are complex and take time to discuss thoroughly, but at some point we need to move beyond in-principle discussions to in-practice discussions informed by the experience of real web developers using Service Workers.

To gain that implementation experience, and to reduce the second type of risk, we have been building sample applications that exercise the feature and inform application model and API discussions.  Over time, the experience of these web developers has helped guide the evolution of Service Workers towards something that’s hopefully useful for web developers more broadly.

Guidelines

Service Workers appear to qualify for shipping under guideline #4. The specification for the feature has been accepted by the appropriate standards working group (i.e., a Working Draft in the W3C WebApps working group).  We've received positive feedback from other browser vendors (i.e., Mozilla and, to a lesser extent, Microsoft) about the feature’s feasibility and value.

Closing thoughts

Shipping Service Workers is a risk.  There’s certainly a chance that other browser implementers will take a different approach to providing web developers network and cache control primitives. We’ve done our best to mitigate this risk through engaging with the W3C and web developers throughout the process, but once we ship Service Workers, we’ll definitely get more feedback from web developers. As a team, we commit to evolving the feature based on this feedback and feedback from other implementers. Hopefully Service Workers will grow into something web developers love.

:DG<

[Ehsan Akhgari]

Hi Dimitri, and everyone else,

I'm with the platform team at Mozilla.  First of all, I would like to thank you and the rest of the Blink team on the effort behind Service Workers.  As many of you know, we have also been working on implementing service workers and have been looking into the spec issues for a while.  One particular issue which is very concerning to us is <https://github.com/slightlyoff/ServiceWorker/issues/445>.  There has been a long discussion on the issue and if you're curious about a summary of Mozilla's concerns with the current design around registrations and scopes, please see <https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60295017>.  Unfortunately it seems like we're not able to come to an agreement.  We have been talking about this internally at Mozilla, and we still believe that this is a serious outstanding flaw of the existing design.  Based on that, at this point it is very likely that we may ship a different and incompatible API than Blink in Firefox that addresses this issue.  I'm not sure how much that's going to affect Blink's decision to ship the existing design, but I still do hope that we can come to an agreement in order to have an interoperable implementation in Firefox and Chrome.  We're planning to keep this conversation going in the future.

Cheers,

Ehsan

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

[Dimitri Glazkov]

On Thu, Oct 23, 2014 at 2:26 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

Hi Dimitri, and everyone else,

I'm with the platform team at Mozilla.  First of all, I would like to thank you and the rest of the Blink team on the effort behind Service Workers.  As many of you know, we have also been working on implementing service workers and have been looking into the spec issues for a while.  One particular issue which is very concerning to us is <https://github.com/slightlyoff/ServiceWorker/issues/445>.  There has been a long discussion on the issue and if you're curious about a summary of Mozilla's concerns with the current design around registrations and scopes, please see <https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60295017>.  Unfortunately it seems like we're not able to come to an agreement.  We have been talking about this internally at Mozilla, and we still believe that this is a serious outstanding flaw of the existing design.  Based on that, at this point it is very likely that we may ship a different and incompatible API than Blink in Firefox that addresses this issue.  I'm not sure how much that's going to affect Blink's decision to ship the existing design, but I still do hope that we can come to an agreement in order to have an interoperable implementation in Firefox and Chrome.  We're planning to keep this conversation going in the future.

Firefox shipping a different API after all this collaborative effort sounds like a terrible outcome. I have full faith in your collective wisdom and trust y'all to reach agreement on this. 

:DG<

[Jake Archibald]

Same goes for id="caches".

We only tested for existence of id= fetch & caches, not for attempted access through window.fetch etc, so we can expect those numbers to be even lower.

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