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

Re: [whatwg] Notifications and service workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 26 Sep 2014 09:09:48 -0700
Message-ID: <CA+c2ei_jOFLQR34Rv8YB6Nbnyd50yAP7JUPL_3NxBAmw+OUWkA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Fri, Sep 26, 2014 at 6:40 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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.

It's a good point that if the above call happens in a SW, then there's
no guarantee that it'll receive either of those callbacks.

So it comes down to if we need "show", and I guess "error", events.

One option that I could think of is that Windows that create a
notification could detect if the notification fails to be displayed,
and if so display in-page UI. Either to replace the notification, or
to indicate to the user that notifications currently don't work. In
this case the above API could work since a SW can't display such UI
anyway, and so it doesn't matter that it might not receive the promise

/ Jonas
Received on Friday, 26 September 2014 16:22:56 UTC

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