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

Re: [whatwg] Notifications and service workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 23 Sep 2014 17:21:01 -0700
Message-ID: <CA+c2ei-aftWkR6TYq5qE1ZhMRGNii0-ms_yRPbvF6+6Z52Rv4g@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>
After having talked to our web developers, and having talked to Olli,
I've come to the following conclusions:

* We should consider the case of persistent notifications separate
from notifications that automatically close when a page goes away.
* Notifications that close when a page goes away does not seem useful
on mobile, but could be useful on desktop to enable minimized
applications, or applications whose window is covered by other
windows, call attention to themselves.
* Persistent vs. non-persistent doesn't seem like a platform
difference, but rather two different types of notifications that
content could want to create.
* For persistent notifications, in cases where the application cares
about the user clicking on the notification (as opposed to
fire-and-forget notifications), we should always send a notification
to the service worker. In this scenario it never seems useful to fire
an event on the Notification instance since that will just mean
multiple codepaths trying to handle the same click. At best that would
be wasted performance, at worst it could mean broken UI or application
* Same applies to "close" in addition to "click".
* For non-persistent notifications, it seems good to not require that
a service worker is used.
* I'm uncertain about if non-persistent notifications are important
enough to target at this point. But I'm heavily biased from having
worked mainly on mobile web lately.
* 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?

/ Jonas

On Tue, Sep 23, 2014 at 6:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> Peter and Jake made a proposal for notifications and service workers,
> but I believe Jonas wanted something without events. I'll outline the
> proposal from Peter and Jake below. Hopefully we can then discuss on
> how to move this forward.
> We add "serviceWorker" to Notification and NotificationOptions. When a
> Notification is constructed within a service worker it is set
> automatically, in other environments it needs to be set to a
> ServiceWorkerRegistration object (allowing it to be overridden inside
> a service worker is probably okay). (If there's an issue with the
> ServiceWorkerRegistration object we throw.)
> If this succeeds, the underlying notification is associated with a
> service worker.
> If a notification is associated with a service worker, events are
> dispatched to the service worker, rather than to Notification objects
> associated with the notification. These events also expose a new
> Notification object (cloning is cheap).
> Suggestions I remember:
> * Expose promises on Notification objects to see whether a
> notification has been clicked or closed. (And keep track of such state
> somewhere.)
> * Dispatch events to Notification objects as well even if the
> notification has an associated service worker. Requiring message
> channel roundtrips for this is cumbersome.
> This is also tracked on GitHub:
> https://github.com/whatwg/notifications/issues/19
> --
> https://annevankesteren.nl/
Received on Wednesday, 24 September 2014 00:22:46 UTC

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