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

Re: [whatwg] Notifications and service workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 24 Sep 2014 17:28:57 -0700
Message-ID: <CA+c2ei-b8o5VfQzR93C_tTB0nW_kwGFYPDHPNOxoXiCa7SRRZg@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 Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> * We should consider the case of persistent notifications separate
>> from notifications that automatically close when a page goes away.
>
> Strawman: We classify existing notifications as non-persistent
> notifications. Only notifications associated with a service worker are
> persistent.

This is a little bit implicit for my taste. But I don't feel very strongly.

> That would also allow us to remove the complexity of
> exposing a single non-persistent notification as multiple Notification
> objects.

Yeah, no matter what syntax we use for creating
persistent/non-persistent notifications, I agree that .get() should
only return persistent notifications.

>> * Right now the spec requires that whenever a user interacts with a
>> persistent notification, the application that created the notification
>> is immediately started so that we can send the appropriate
>> click/close/future-button-press event to it's service worker. This can
>> be quite expensive. At the very least applications need to be able to
>> indicate that they don't need to be told about the "close" event.
>> * Even better would likely be content could indicate which events they
>> want fired at the service worker when creating a Notification. Other
>> events would be dropped. This list vary by-notification, not by-app.
>> * Alternatively, maybe we could simply get rid of the "close" event
>> entirely. Does it have a use-case?
>
> Is this only about the close event? We could opt not to support for
> persistent notifications as a start if we follow my strawman above.
> I'm not a 100% sure why it's there either at this point. I suspect not
> supporting it would not necessarily break anything. Probably mostly
> there for symmetry with the close() method.

Actually, it might also be the "show" event.

But see also my sub-thread with Tab. It *might* be useful to not
receive a "click" event for persistent notifications. I don't know of
any use cases, but my gut feeling is that they are there.

But maybe they are rare enough that by default we only fire "click"
events. For persistent notifications we fire them at the SW, for
non-persistent at the Notification object.

If we in the future find actual use cases for "close"/"show" we can
add ways to opt in to receiving those. And if we find use cases for
*not* receiving "click" (in particular to SW) we can add ways to opt
out of those.

/ Jonas
Received on Thursday, 25 September 2014 00:29:55 UTC

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