Intent to Ship: Web Notifications Service Worker API

204 views
Skip to first unread message

Peter Beverloo

unread,
Feb 6, 2015, 1:00:56 PM2/6/15
to blink-dev

Contact emails

pe...@chromium.org, owe...@chromium.org (pm)


Spec

https://notifications.spec.whatwg.org/#service-worker-api


Summary

The ability to create persistent notifications through ServiceWorkerRegistration.showNotification(). These notifications will be able to outlive the tab they were created by. When they get clicked on by the user, the associated Service Worker will be started (if needed) and the “notificationclick” event will be invoked. The developer can then focus existing windows, or create new ones.


On Android, we do not require the browser to be running at all for this feature to work. Desktop Chrome does have to run in order for the notifications to be displayed or to be interacted with.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/AqIGfI3Pv68/aw0vj1Ww1wgJ


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

Windows, Mac, Linux, Chrome OS: Yes.

Android: Yes, on Android Jelly Bean and later due to the the notification UX we’d like to offer, which is unavailable on Android ICS.

Android WebView: No, because it’s not yet obvious how to support this in the WebView API. Tracked in https://crbug.com/434712


Demo link

https://johnme-gcm.appspot.com/chat/ -- also uses the Push API.


Compatibility Risk

Blink is the first browser engine to support the Service Worker-based Web Notifications API. Much of the discussion, however, has been led by Mozilla’s Anne van Kesteren (the editor) and Jonas Sicking.


We do not yet support the Notification.get() accessor for getting persistent notifications, nor many of the other new properties from the specification.


Addition of other new features is tracked in https://crbug.com/442145 and will be covered in future Intent to Implement and Ships.


OWP launch tracking bug?

https://crbug.com/426436


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5480344312610816


Alex Russell

unread,
Feb 6, 2015, 1:07:24 PM2/6/15
to Peter Beverloo, blink-dev

Gonna sound like a broken record here, but this is *amazing*. If I could LGTM it, I would early and often and encourage OWNERS to.

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

ad...@chromium.org

unread,
Feb 6, 2015, 1:12:45 PM2/6/15
to blin...@chromium.org
Non-owner LGTM. This is *really* awesome.

Chris Harrelson

unread,
Feb 6, 2015, 7:39:43 PM2/6/15
to ad...@chromium.org, blin...@chromium.org
LGTM

Philip Jägenstedt

unread,
Feb 10, 2015, 1:11:37 AM2/10/15
to Chris Harrelson, ad...@chromium.org, blink-dev
LGTM2

Peter has let us (Opera) know off-list that this entails some work for
clients of the content API, which could be relevant to others as well:

> M42 contains some //content API changes that
> seem reasonably easy to resolve, but will actually end up exposing
> ServiceWorkerRegistration.showNotification() (persistent notifications --
> assuming the Intent to Ship gets enough LGTMs) without providing the
> appropriate functionality. Unless you implement the full
> start-service-worker-in-a-background-Android-Service loop, opening and
> focusing windows from a background service, and so on, which is non-trivial,
> you'll probably want to make sure the ServiceWorkerNotifications Blink
> runtime flag continues to be disabled.

(I don't know if it will initially be disabled in Opera or not, I've
notified the relevant people internally.)

Philip

TAMURA, Kent

unread,
Feb 10, 2015, 1:56:07 AM2/10/15
to Philip Jägenstedt, Chris Harrelson, ad...@chromium.org, blink-dev
LGTM3

--
TAMURA Kent
Software Engineer, Google


Reply all
Reply to author
Forward
0 new messages