Intent to ship: Service Workers with FetchEvent

[Ben Kelly]

In Firefox 44 we intend to enable Service Workers and FetchEvents by
default on desktop and android. These features will not be enabled on
Firefox OS yet.

They has been developed behind the following preferences:

dom.serviceWorkers.enabled
dom.serviceWorkers.interception.enabled
dom.serviceWorkers.interception.opaque.enabled

Chrome has been shipping Service Workers with FetchEvent since Chrome 40.

Unfortunately, I can't find a previous intent to implement for service
workers.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1226686
Standard:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html

Please let me know if you have any questions are concerns.

Thanks.

Ben

[Brian Grinstead]

Also, webconsole logging for Service Workers is preffed behind devtools.webconsole.filter.serviceworkers, which will be enabled by default in https://bugzilla.mozilla.org/show_bug.cgi?id=1201962.

Brian

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Boris Zbarsky]

On 11/20/15 1:34 PM, Ben Kelly wrote:
> Please let me know if you have any questions are concerns.

I actually have a few questions.

1) How confident are we that the spec is stable/correct?

2) How confident are we that our implementation, Chrome's, and the spec
all match? I know we were working on importing some of their tests, so
I'm guessing fairly confident, but just wanted to check.

3) Have we heard anything from Apple or Microsoft about their plans, or
lack thereof, for Service Workers?

4) Are there significant parts of the spec we're not shipping yet? Is
Chrome shipping those parts? Is support for those feature-detectable?

-Boris

[Ben Kelly]

On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>
> 1) How confident are we that the spec is stable/correct?
>

The spec is converging to a stable v1, but things are still changing. The
core functionality has been stable for a while, though.

> 2) How confident are we that our implementation, Chrome's, and the spec
> all match? I know we were working on importing some of their tests, so I'm
> guessing fairly confident, but just wanted to check.
>

We imported blink's web-platform-tests. We found some spec issues with
them and tried to flow them all back to both spec and google.

There are some corner cases where we differ or might differ depending on
release schedules. For example, the spec now says that navigations should
set a RequestMode of "navigate", but neither chrome or firefox do this. We
set "same-origin" as the spec used to say. I believe chrome has patches in
flight to change, but we have not started yet.

Another compat issue we need to fix is returning the same
ServiceWorkerRegistration object repeatedly from certain APIs. This was
something that changed a few times in both the spec and chrome.

Fixing these minor compat issues is on our todo list for the rest of the 45
cycle leading up to orlando.

Also, we have implemented more of the spec in some areas than chrome. For
example, I believe chrome's Cache API is still not complete on their
release channel. We have a complete Cache API already shipped in FF39.

> 3) Have we heard anything from Apple or Microsoft about their plans, or
> lack thereof, for Service Workers?
>

They have been attending face-to-face meetings, but no official
implementation announcements as far as I know.

The webkit project's 5 year plan includes service workers:

http://trac.webkit.org/wiki/FiveYearPlanFall2015

> 4) Are there significant parts of the spec we're not shipping yet? Is
> Chrome shipping those parts? Is support for those feature-detectable?
>

I don't think we are missing anything significant in the service worker
spec. Other features building on top of service workers like push,
background-sync, etc are in separate specs.

Fetch body streams is something that was spec'd recently. Chrome has it
partly implemented, but I don't think their shipping implementation is spec
compatible.

I believe all these APIs are feature detectable.

Overall I expect to get reports of compat issues. I think thats inevitable
with such a large feature and complex feature. We'll have to hash it out
in spec issues, write WPT tests, and ship the fix. I'm not sure how else
to realistically move forward, though.

I hope that answers your questions.

Thanks.

Ben

[Ben Kelly]

On Fri, Nov 20, 2015 at 3:21 PM, Ben Kelly <bke...@mozilla.com> wrote:

>
> On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
>>

>> 1) How confident are we that the spec is stable/correct?
>>
>

> The spec is converging to a stable v1, but things are still changing. The
> core functionality has been stable for a while, though.
>

I guess I should mention the biggest change in the spec that has not been
implemented by either chrome or firefox.

The spec now exposes the Response.url passed to the
FetchEvent.respondWith() to the outer network request. So base URLs for
stylesheets and workers will have a different URL. A window doing fetch()
will see a different Response.url.

This was changed so that relative path subresources in stylesheets and
workers will continue to work.

I've mentioned to google it would be helpful to do a coordinated release
for this particular spec change. Here is the chrome issue:

https://code.google.com/p/chromium/issues/detail?id=553535

Ben

[Boris Zbarsky]

On 11/20/15 3:21 PM, Ben Kelly wrote:
> The spec is converging to a stable v1, but things are still changing. The
> core functionality has been stable for a while, though.

OK. I guess my question is whether, for example, waiting for another
release cycle would significantly improve things here or not. I'm not
saying we necessarily should, just trying to understand the tradeoffs.

> There are some corner cases where we differ or might differ depending on
> release schedules. For example, the spec now says that navigations should
> set a RequestMode of "navigate", but neither chrome or firefox do this. We
> set "same-origin" as the spec used to say. I believe chrome has patches in
> flight to change, but we have not started yet.

OK. That sort of thing is going to happen, as long as the spec is in flux.

> Another compat issue we need to fix is returning the same
> ServiceWorkerRegistration object repeatedly from certain APIs. This was
> something that changed a few times in both the spec and chrome.
>
> Fixing these minor compat issues is on our todo list for the rest of the 45
> cycle leading up to orlando.

OK. Are there plans to uplift any of this to 44?

> The webkit project's 5 year plan includes service workers:

Great, thanks.

> I don't think we are missing anything significant in the service worker
> spec. Other features building on top of service workers like push,
> background-sync, etc are in separate specs.

Gotcha. Is there risk in pages assuming that if we implement the piece
we implement then we also implement this other stuff?

> I believe all these APIs are feature detectable.

Great, that should help with people not assuming stuff.

> Overall I expect to get reports of compat issues.

That's fair. Again, the main question I have is whether giving our impl
and the spec more bake time would help with this or just push it off
while leaving the scope of the problem about the same. It sounds like
you don't think it would really help, right?

-Boris

[Ben Kelly]

On Fri, Nov 20, 2015 at 3:30 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>
> Another compat issue we need to fix is returning the same
>> ServiceWorkerRegistration object repeatedly from certain APIs. This was
>> something that changed a few times in both the spec and chrome.
>>
>> Fixing these minor compat issues is on our todo list for the rest of the
>> 45
>> cycle leading up to orlando.
>>
>
> OK. Are there plans to uplift any of this to 44?
>

No. I think what we have works on the sites/demos/wpt tests available
today. We feel its compatible enough to ship. We'll fix further compat
issues using our standard train model.

> Overall I expect to get reports of compat issues.
>>
>
> That's fair. Again, the main question I have is whether giving our impl
> and the spec more bake time would help with this or just push it off while
> leaving the scope of the problem about the same. It sounds like you don't
> think it would really help, right?

I think the best thing we can do right now is get a second implementation
into wide circulation. This will highlight compat issues yes, but also
help avoid baking chrome specific behavior into all the sites using service
workers.

Ben

[Boris Zbarsky]

On 11/20/15 3:26 PM, Ben Kelly wrote:
> I guess I should mention the biggest change in the spec that has not been
> implemented by either chrome or firefox.
>
> The spec now exposes the Response.url passed to the
> FetchEvent.respondWith() to the outer network request. So base URLs for
> stylesheets and workers will have a different URL. A window doing fetch()
> will see a different Response.url.
>
> This was changed so that relative path subresources in stylesheets and
> workers will continue to work.

OK. So here the main risk that we'll ship something that has one
relative path behavior, people will start using it, then we will switch
it, right?

Do we have a timeframe on when we could do the switch, ignoring for hte
moment coordination problems with Google?

-Boris

[Boris Zbarsky]

On 11/20/15 3:42 PM, Ben Kelly wrote:
> No. I think what we have works on the sites/demos/wpt tests available
> today. We feel its compatible enough to ship. We'll fix further compat
> issues using our standard train model.

OK.

> I think the best thing we can do right now is get a second implementation
> into wide circulation. This will highlight compat issues yes, but also
> help avoid baking chrome specific behavior into all the sites using service
> workers.

Alright. Sounds scary, but I trust you've thought this stuff through.

-Boris

[Robert O'Callahan]

On Sat, Nov 21, 2015 at 9:42 AM, Ben Kelly <bke...@mozilla.com> wrote:

> I think the best thing we can do right now is get a second implementation
> into wide circulation. This will highlight compat issues yes, but also
> help avoid baking chrome specific behavior into all the sites using service
> workers.
>

Yes. This is incredibly important. Just look at the messaging in
http://recode.net/2015/11/09/indias-flipkart-google-launch-chrome-mobile-website-replicate-apps/

Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

[Ehsan Akhgari]

To close the loop here, I just enabled service workers on Firefox 44
(currently on Aurora.)

Thanks to everyone who helped make this happen. It was a loooong ride. :-)

On Fri, Nov 20, 2015 at 5:24 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
Ehsan