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

Re: [whatwg] Notifications and service workers

From: Peter Beverloo <beverloo@google.com>
Date: Fri, 26 Sep 2014 15:36:56 +0100
Message-ID: <CALt3x6mebz+LOVGPMA_iAxpcgoYHM-gz_LRkWiWMNVbJUkNXxA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Andrew Wilson <atwilson@google.com>
Let me reply to a few points mentioned in this thread -- it's quite
overloaded :-).

I've also added Andrew, who might know some historical reasons for the
events. (Andrew: most of this is in context of persistent notifications.)

* Life-time of existing notifications.

Chrome currently treats Web Notifications as "persistent" ones. When the
page goes away, the notification stays. Interaction with the notification
is not going to trigger anything anymore. While I'm in favor of changing
this, we have to be very cautious to not break user expectations of
existing users of the Web Notification API, for example in calendar

* Dropping the close event.

I've been wondering myself whether it's valuable to support this. Like Tab,
I'm not aware of any messaging application actually using the close event
as an indication that the message has been read. There is the "dismiss all"
button on most platforms, which definitely does not imply having read the
message. It's actually an interesting privacy question as well, for
example, if a user dismisses a Facebook notification in their notification
center without actually starting the app, should the sender be informed
about them having at least looked at their phone?

Synchronizing closing of the notification on all the user's devices is an
interesting one, but opt-in would be sufficient for this.

Given the cost of starting up a Service Worker, I'm interested in exploring
opt-in. One potential optimization a UA could do is detect the events bound
on a Service Worker's global when it starts, and check whether
"notificationclose" is part of this for future invocations.

* Dropping the show event.

There is one scenario in which Chrome doesn't fire the show event, and
that's when no permission has been granted to show notifications (in which
case we fire the error event). One theoretical concern with this property
is that if we choose to support delayed notifications, it could be used to
set precise timers. Depending on how we're going to deal with
(asynchronous) errors for persistent notifications, I'm fine with dropping
this for them.

* Supporting non-persistent notifications in Service Workers.

I'd prefer not to, especially if we would auto-close the notifications.
There seems to be little point beyond indicating to the user that the
Service Worker is running, which feels more like a UA thing if they choose
to do so.

* Supporting non-persistent notifications in Shared and Dedicated Workers.

As long as we continue to support non-persistent notifications, I see no
reason not to do this. The globals of both kinds of workers have well
defined lifetimes, making the notifications as reliable as in-page ones,
most notably on desktop.

* Not using the constructor for persistent notifications.

There is one more argument to make in favor of creating a promise
somewhere, and that's consistency with other Service Worker based APIs. As
I understand it, both Web Push and Background Sync are planning to expose
their creation methods on the ServiceWorkerRegistration object. If we were
to do something analogous, it'd be:

navigator.serviceWorker.ready.then(function (registration) {
    registration.createNotification('Title', { ... });

Instead of:

navigator.serviceWorker.ready.then(function (registration) {
  new Notification('Title', { serviceWorker: registration });

I have no strong feelings here either, and think it's fine to continue
using the constructor with the serviceWorker property set. Both would still
use the Notification statics. Having a promise would clean up the error
handling a bit, which may occur in the no-permission case.

* "Extra-persistent" notifications (non-removable ones)

Let's have a separate thread about this. I think it's a loaded subject
given that it's incredibly easy to badly annoy the user when using these,
and we have to make some careful considerations here.


On Fri, Sep 26, 2014 at 2:41 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > None of Twitter, Hangouts, or IRCCloud cares a whit if you close their
> > notifications; they still record stuff as unread until you actually
> > visit the app.  I can't recall any other app I've ever used treating a
> > notification closing as a significant event and taking any action,
> > either.  So, at least based on my immediate testing and long-term
> > memory of the notification patterns of the apps I use, I don't think
> > there's any use-case for a close event.
> Jake, would be interesting to hear your thoughts on this. If we can
> simplify notifications by getting rid of some events I'm all for it.
> --
> https://annevankesteren.nl/
Received on Friday, 26 September 2014 14:37:33 UTC

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