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

Re: [whatwg] Notifications and service workers

From: Andrew Wilson <atwilson@google.com>
Date: Mon, 29 Sep 2014 08:15:17 +0200
Message-ID: <CAArhhis6Oe2S38RxFkNNRiERkvg-rgaaj2TpgU9yhiiUz-Fk1A@mail.gmail.com>
To: Peter Beverloo <beverloo@google.com>
Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>
Apologies if I miss some subtleties in the preceding discussion - I've
scanned the thread, but I haven't been following closely.

On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo <beverloo@google.com> wrote:

> 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
> applications.

I suspect it's OK to change this, especially since (for Chrome, at least)
most platforms are moving to a model where notifications don't stay on the
screen anyway (they move to a notification center). That said, I've never
really understood the interest in auto-closing notifications, since if a
web page wants to close its notifications, it's trivial to do so in an
onclose handler - I guess the issue might be notifications coming from a
worker, where the worker doesn't get notified that it's going away? Maybe
the right fix is that workers should get a close event also :)

In any case, agreed with Jonas that if we're going to build non-persistent
notifications, then perhaps they should have a fixed time limit (possibly
UA-adjustable) and not be tied explicitly to a source's lifetime.

> * 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?

Gmail tracks information internally about all open notifications so it
knows what chat window, email, etc to display when the user clicks on one.
It cleans up those data structures as notifications are closed, so if we
stop generating close events, then gmail will leak even more memory than it
currently does :)

> 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.

I'm not aware of any particular use cases here. Gmail isn't listening to
show events, AFAICT.

> * 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.
> Thanks,
> Peter
> 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 Monday, 29 September 2014 06:16:03 UTC

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