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

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.


-- 
http://annevankesteren.nl/

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