W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 5 Aug 2014 16:48:00 +0200
Message-ID: <CADnb78jKoJnGPr2DnJ_gMFY1+TJF6xX4vTdX_6ivbt-a_qoHSg@mail.gmail.com>
To: Peter Beverloo <beverloo@google.com>
Cc: WHATWG <whatwg@whatwg.org>
On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo <beverloo@google.com> wrote:
> When used from a Service Worker, the attribute will implicitly default to
> the ServiceWorkerRegistration of the running Service Worker.

Is that available within a service worker?

> If serviceWorker is set to null/undefined within a ServiceWorker context, a
> TypeError will be thrown.

I thought the idea was to have it default somehow. It seems to me
within a service worker you cannot specify it and you simply always
get a notification associated with that service worker.

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

We could throw a TypeError. (DOMError is not a thing.) Equivalent to
what happens when you get the type wrong.

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

So with each event you get a new instance of the object? I guess
that's probably what we want given how getClones() et al work. A bit
wasteful, but not too bad.

Received on Tuesday, 5 August 2014 14:48:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC