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

On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

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

It would be reasonable to expose it, but it currently isn't (afaik).

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

Defaulting to the current Service Worker sounds good.

One case Jake and I thought of was if/when a Service Worker could get
registrations for other SWs in the origin, but that's only a theoretical
case today.

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

I think it would be nice to be able to distinguish the invalid-value-type
case from the no-service-worker case, wouldn't you lose that by throwing
TypeErrors in both cases?

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

I don't think this is a massive problem, in general Notification objects
will be very small (depending on the data property, of course).

Peter

--
> http://annevankesteren.nl/
>

Received on Tuesday, 5 August 2014 15:05:01 UTC