Re: [whatwg] Notifications improvements

For what it's worth. I'm not actively working on notifications at the
moment. If anything is about to be implemented please ping the
relevant issue and I'll try to prioritize it somehow. More detailed
design sketches appreciated.

On Wed, Aug 6, 2014 at 12:16 AM, Jonas Sicking <> wrote:
> The place that this has come up in FirefoxOS is when notifying about
> incoming emails. We would like to display the sender and the subject
> for each newly arrived email.
> At first this seemed like a pretty unusual edge case, but after
> looking at chrome-apps notification API they had this exact feature.
> So it seemed like this has come up elsewhere too.

This is now

> The goal of a Date field for notifications is quite different. It's to
> enable a notification that's associated with an event that happend, or
> is going to happen, at a different time than when the notification API
> JS call happened.

Ah yes, we discussed this but I forgot to track it somewhere:

>>> We also need to keep state on the Notification object if the user has
>>> clicked the notification or not.
>> Why is that?
> Relying on the application to track this perfectly has two problems.
> First off it means that applications has to register a ServiceWorker
> handler for all notification objects and run any logic related to
> handling a click right away. Rather than simply handle it next time
> the application is started, which would save on both CPU and battery.

The current service worker proposal does not have a feature of having
a handler per notification. Rather, you register for
"notificationclick" and get an event for each such thing. Up to the
discretion of the user agent of course.

> Second, it's much more error prone to track this in application space
> given potential for bugs, crashes and IO errors.

If we do this it would be the first thing that would actually require
changing a Notification object instance. At the moment the whole thing
is static.


Received on Wednesday, 6 August 2014 11:16:29 UTC