Intent to Ship: Service Worker APIs needed to support Notifications and Push API

[Kenji Baheux]

Contact emails

Engineering: nhi...@chromium.org, mlam...@chromium.org

(PM: kenji...@chromium.org)

Spec

Editor's draft (W3C Public Working Draft)

Summary

This intent to ship adds the following Interface and APIs to the Service Worker subset we already shipped:

• openWindow() method on Clients

• WindowClient/Client full-fledged interfaces

• surfacing ServiceWorkerRegistration in the ServiceWorkerGlobalScope

API level detail (relevant changes in bold italic)

Use cases

These APIs enable Notifications and Push API use cases.

openWindow() allows you to open your website when the user acts on a notification for instance. It has some restrictions in place to prevent abuse, similar to restrictions for when an algorithm is “allowed to show a popup” in the HTML spec.

WindowClient/Client has attributes that let you find out if there is already a window opened to your website as well as methods for focusing on a particular window. Focusing has the same restrictions as openWindow().

Surfacing ServiceWorkerRegistration in the ServiceWorkerGlobalScope is needed for managing Push registrations. It also allows you to call showNotification within a push event handler.

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 in the console when Service Worker registration fails.

Compatibility Risk (SW side changes)

Pluses and minuses:

+ A third public working draft of the spec has been published on Feb 5th.

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

+ The team has been writing W3C testharness.js tests first, and only using Blink-specific tests for crashing, GC-related things and features that need manual testing. We plan to upstream the former kind to W3C.

- openWindow is not yet implemented in Firefox (main branch)

- (ServiceWorker)Clients/(ServiceWorker)Client are present but based on old definitions and therefore not compatible with our tests

- The spec is under active development. Relevant item for this intent to ship:

  - some minor aspects of the openWindow restrictions are still being discussed: timeout value, scope of capability. Minimizing factor: we are taking a conservative stance by only allowing opening regular window and opting for a reasonable timeout value (the timeframe for allowing popups is actually described as user-agent defined in the HTML spec).

OWP launch tracking bug?

http://crbug.com/446843

Link to entry on the feature dashboard

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

--

Kenji BAHEUX

Product Manager - Chrome

Google Japan

[Alex Russell]

This is the most exciting thing to happen to the web platform since Service Workers. Can't +1 hard enough. My kingdom for an LGTM!

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

[Kenji Baheux]

Mounir's intent to ship post had the following nifty items that I missed:

First off, I should have noted that openWindow doesn't work in a webview context.

But more importantly, I should have had a link to Mounir's demo showing off openWindow and focus.

Here it is:  https://mounirlamouri.github.io/sandbox/sw-open-focus-window/test.html 

And a a freebie link for the Push demo app can't hurt so here you go:
https://johnme-gcm.appspot.com/chat/ 

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

[Chris Harrelson]

LGTM

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

[Philip Jägenstedt]

This also looks like goodness, but some comments nevertheless:

1. The openWindow() error handling does not seem to be quite per spec:

• It uses SyntaxError instead of TypeError for an invalid URL.
  
• The cross-origin SecurityError case does not seems to be in the spec.
  
• The spec references allowed to show a popup, but the implementation doesn't use UserGestureIndicator like most other instances of this concept that I'm aware of, like LocalDOMWindow::allowPopUp and Fullscreen::requestFullscreen. If the existing concept isn't usable, then the new concept needs to be standardized as well.

It looks like there aren't any tests for the error handling, but I could be looking in the wrong place.

2. Does "WindowClient/Client full-fledged interfaces" correspond to ServiceWorkerClientAttributes and thus include Client.url?

3. It looks like ServiceWorkerGlobalScope's readonly attribute ServiceWorkerRegistration registration is already unconditionally enabled.

As a general comment, it would be easier to evaluate an incremental Intent to Ship like this given the CLs which would make it so or have already made it so.

Philip

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

[Kenji Baheux]

1. The openWindow() error handling does not seem to be quite per spec:

• It uses SyntaxError instead of TypeError for an invalid URL.
  
• The cross-origin SecurityError case does not seems to be in the spec.
  
• The spec references allowed to show a popup, but the implementation doesn't use UserGestureIndicator like most other instances of this concept that I'm aware of, like LocalDOMWindow::allowPopUp and Fullscreen::requestFullscreen. If the existing concept isn't usable, then the new concept needs to be standardized as well. 

It looks like there aren't any tests for the error handling, but I could be looking in the wrong place.

cc/ Mounir who has been driving the implementation of openWindow and discussed some spec aspects.

 

 

2. Does "WindowClient/Client full-fledged interfaces" correspond to ServiceWorkerClientAttributes and thus include Client.url?

You are correct (I fixed the document over the weekend).

 

3. It looks like ServiceWorkerGlobalScope's readonly attribute ServiceWorkerRegistration registration is already unconditionally enabled.

Ideally, we should have these behind a flag, send an intent to ship and enable by default if we obtain the 3 LGTMs.

Here, we have a tentative state (implemented and enabled) and an intent to ship as-is provided that we obtain the 3 LGTMs.

The post branch-cut outcome is the same but I can see why this might be confusing.

We'll try to adjust toward the ideal shape for our future intent to ship.

 

As a general comment, it would be easier to evaluate an incremental Intent to Ship like this given the CLs which would make it so or have already made it so.

Thanks for the suggestion, we'll give it a try for the next intent to ship.

 

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

[Philip Jägenstedt]

Thanks Kenji,

About "ServiceWorkerGlobalScope's readonly attribute
ServiceWorkerRegistration registration", as you say the outcome is the
same, I just wanted to double-check.

I'll await Mounir's feedback on the error handling. That's pretty
trivial, so LGTM on the assumption that it'll be sorted one way or
another.

Philip

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

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

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

[Mounir Lamouri]

On Sun, 8 Feb 2015, at 15:15, Philip Jägenstedt wrote:
> This also looks like goodness, but some comments nevertheless:
>
> 1. The openWindow() error handling does not seem to be quite per spec:
>

> - It uses SyntaxError instead of TypeError for an invalid URL.

I do not like TypeError, it doesn't make any sense and doesn't advertise
the real problem. The reason why it's TypeError instead of SyntaxError
is because the URL spec is full of TypeError because Anne believe it's a
good idea. If you strongly believe that I should switch to TypeError
here, I can do that.

> - The cross-origin SecurityError case does not seems to be in the
> spec.

This is explained in the more complete intent to ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/6JqLuKcClJo/152_urU6sjYJ

> - The spec references allowed to show a popup
> <https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup>,

> but the implementation doesn't use UserGestureIndicator like most
> other
> instances of this concept that I'm aware of, like
> LocalDOMWindow::allowPopUp and Fullscreen::requestFullscreen. If the
> existing concept isn't usable, then the new concept needs to be
> standardized as well.

Same, you can find more information about what we are doing here:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/6JqLuKcClJo/152_urU6sjYJ

The reason why I am not using UserGestureIndicator is because I wanted
something to be scoped to the ExecutionContext, not the process nor on
the stack (which are the two current systems).

Also, for what it's worth, security wise, there are no plans in allowing
going fullscreen when a notification is clicked, see:
https://github.com/whatwg/notifications/issues/30
I wouldn't take the "allow to show a popup" as strongly normative. The
spec isn't very mature on that point.

> It looks like there aren't any tests for the error handling, but I could
> be
> looking in the wrong place.

Because of the joy of three-sided CLs, the tests are not landed yet but
can be found here:
https://codereview.chromium.org/896043004
https://codereview.chromium.org/879403005
https://codereview.chromium.org/866043005

> 2. Does "WindowClient/Client full-fledged interfaces" correspond to
> ServiceWorkerClientAttributes
> and thus include Client.url?

Good catch, yes.

-- Mounir

[Jochen Eisinger]

LGTM3

[Philip Jägenstedt]

On Tue, Feb 10, 2015 at 6:09 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On Sun, 8 Feb 2015, at 15:15, Philip Jägenstedt wrote:
>> This also looks like goodness, but some comments nevertheless:
>>
>> 1. The openWindow() error handling does not seem to be quite per spec:
>>
>> - It uses SyntaxError instead of TypeError for an invalid URL.
>
> I do not like TypeError, it doesn't make any sense and doesn't advertise
> the real problem. The reason why it's TypeError instead of SyntaxError
> is because the URL spec is full of TypeError because Anne believe it's a
> good idea. If you strongly believe that I should switch to TypeError
> here, I can do that.

A quick look at some other specs shows that both TypeError and
SyntaxError are used for invalid URLs:
https://fetch.spec.whatwg.org
https://html.spec.whatwg.org
https://url.spec.whatwg.org
https://xhr.spec.whatwg.org

In Blink, I see AbstractWork, Credential, EventSource and WebSocket
using SyntaxError while Fetch, RTCPeerConnection and URL use
TypeError. XMLHttpRequest.open() seems to actually never throw.

Anne, can you clue us in about why TypeError everywhere is the way to
go? Is it so that a WebIDL URLString type can be added later on?

Mounir, I honestly don't think the exception type is important, but
for any deliberate spec violation, a comment in the code pointing to a
spec bug tracking the issue is useful I think.

>> - The cross-origin SecurityError case does not seems to be in the
>> spec.
>
> This is explained in the more complete intent to ship:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/6JqLuKcClJo/152_urU6sjYJ
>
>> - The spec references allowed to show a popup
>> <https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup>,
>> but the implementation doesn't use UserGestureIndicator like most
>> other
>> instances of this concept that I'm aware of, like
>> LocalDOMWindow::allowPopUp and Fullscreen::requestFullscreen. If the
>> existing concept isn't usable, then the new concept needs to be
>> standardized as well.
>
> Same, you can find more information about what we are doing here:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/6JqLuKcClJo/152_urU6sjYJ

Thanks. Since these differences are observable, is there a spec bug to
specify make spec and implementation align?

> The reason why I am not using UserGestureIndicator is because I wanted
> something to be scoped to the ExecutionContext, not the process nor on
> the stack (which are the two current systems).
>
> Also, for what it's worth, security wise, there are no plans in allowing
> going fullscreen when a notification is clicked, see:
> https://github.com/whatwg/notifications/issues/30
> I wouldn't take the "allow to show a popup" as strongly normative. The
> spec isn't very mature on that point.

Every time I've tried some interpretation of a spec, I've been sternly
told (by Hixie) to take everything at face value and not read between
the lines :)

It really sounds like this is a new model, in particular if fullscreen
should not be allowed, and that it needs spec'ing.

>> It looks like there aren't any tests for the error handling, but I could
>> be
>> looking in the wrong place.
>
> Because of the joy of three-sided CLs, the tests are not landed yet but
> can be found here:
> https://codereview.chromium.org/896043004
> https://codereview.chromium.org/879403005
> https://codereview.chromium.org/866043005

Thanks!

Philip

[Mounir Lamouri]

Sure, will open an issue.

> >> - The cross-origin SecurityError case does not seems to be in the
> >> spec.
> >
> > This is explained in the more complete intent to ship:
> > https://groups.google.com/a/chromium.org/d/msg/blink-dev/6JqLuKcClJo/152_urU6sjYJ
> >
> >> - The spec references allowed to show a popup
> >> <https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup>,
> >> but the implementation doesn't use UserGestureIndicator like most
> >> other
> >> instances of this concept that I'm aware of, like
> >> LocalDOMWindow::allowPopUp and Fullscreen::requestFullscreen. If the
> >> existing concept isn't usable, then the new concept needs to be
> >> standardized as well.
> >
> > Same, you can find more information about what we are doing here:
> > https://groups.google.com/a/chromium.org/d/msg/blink-dev/6JqLuKcClJo/152_urU6sjYJ
>
> Thanks. Since these differences are observable, is there a spec bug to
> specify make spec and implementation align?

For the same-origin limitation, it's something for us to fix. For the
notificationclick behaviour, Jake is working on this. There are bugs
opened.

> > The reason why I am not using UserGestureIndicator is because I wanted
> > something to be scoped to the ExecutionContext, not the process nor on
> > the stack (which are the two current systems).
> >
> > Also, for what it's worth, security wise, there are no plans in allowing
> > going fullscreen when a notification is clicked, see:
> > https://github.com/whatwg/notifications/issues/30
> > I wouldn't take the "allow to show a popup" as strongly normative. The
> > spec isn't very mature on that point.
>
> Every time I've tried some interpretation of a spec, I've been sternly
> told (by Hixie) to take everything at face value and not read between
> the lines :)

Even the HTML spec is not quite right about popup handling. It's quite
browser specific.

> It really sounds like this is a new model, in particular if fullscreen
> should not be allowed, and that it needs spec'ing.

Jake is working on that.

-- Mounir

[Philip Jägenstedt]

LGTM4, it sounds like there's some kind of path forward for all of the
discrepancies discussed here. Can you paste a list of the relevant
spec and Chromium issues for easy reference?

Philip