On Tue, Aug 5, 2014 at 3:48 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Tue, Jul 29, 2014 at 4:28 PM, Peter Beverloo <bever...@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/ >