To summarize a discussion we had about this on IRC today:

Jungkee wrote a helpful document for features using Service Workers as well:

The |serviceWorker| attribute can be added to the NotificationOptions
dictionary and to the Notification interface, and should be set by the
developer to the ServiceWorkerRegistration instance.

navigator.serviceWorker.ready.then(function(registration) {
    new Notification(‘Hello, World!’, {
        serviceWorker: registration

When used from a Service Worker, the attribute will implicitly default to
the ServiceWorkerRegistration of the running Service Worker. If
serviceWorker is set to any non-SWR value, a TypeError will be thrown. If
serviceWorker is set to null/undefined within a ServiceWorker context, a
TypeError will be thrown.

1. If registration.activeWorker is null, then:
    1. Throw a DOMError with name “InvalidStateError”
    2. Abort these steps.

Events will be delivered to either the Notification instance, or to the
Service Worker, not both. All four events will be exposed to a Service
Worker [onnotificationshow, onnotificationclick, onnotificationclose,
onnotificationerror]. The events will receive a NotificationEvent which
will contain a notification instance.


On Fri, May 16, 2014 at 3:17 PM, Anne van Kesteren <> wrote:

> On Fri, May 16, 2014 at 4:02 PM, Peter Beverloo <>
> wrote:
> > On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren <>
> wrote:
> >> Service worker integration makes sense to me. I guess I'll wait with
> >> updating the Notifications API until that is further along.
> >
> > Do you have a specific milestone in mind?
> Probably once it exposes a stable hook for "does the current global
> have an associated service worker". And if I am to define the service
> worker events I suppose some more hooks are needed. Having service
> workers in two implementations would also help, as at that point the
> stability is a lot less uncertain.
> --

Reply via email to