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

Re: [whatwg] Notifications and service workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 26 Sep 2014 15:40:13 +0200
Message-ID: <CADnb78insgboYGOz4t+ByTGFqKfsy_5ZrTZu0rm0_gGqnwJvJQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> promise = createPersistentNotification(...);
>>> promise.then(notificationWasShown, notificationWasRejected);
>>
>> Well presumably we still want to share an object of sorts as part of
>> the event, so all the notification data is exposed somehow. A promise
>> does not make much sense to me as a service worker can be killed at
>> any point.
>
> I'm not sure I understand what you are saying here. The above code is
> the creation steps, not the notification steps.

Oh, but shown implies it's displayed, which currently can happen
later. But as per the other thread maybe we should get rid of that.
Assuming we get rid of that, this seems to help a bit with error
handling, but is otherwise mostly identical in approach to just
keeping the constructor.


> I agree that the "click" event needs to expose the Notification
> object. But the SW "click" event needs to be fired at the SW global,
> and have as one of its properties the Notification object. Exactly
> because the SW might have been killed previously and is just getting
> spawned in order to fire the "click" event. Thus no other references
> to the Notification object might exist.

Sure.


-- 
https://annevankesteren.nl/
Received on Friday, 26 September 2014 13:40:41 UTC

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