[whatwg] Notifications: usage feedback

[James Burke]

This Notifications feedback comes from using them in FirefoxOS for the
email web app. It uses an alarm API to periodically wake up, do an
email sync, and if new messages, creates some Notifications. The web
app may also shut itself down if it was not already opened in a
visible state. The OS may also decide to kill it to use the memory for
some other app.

1) Ability to pass data with the Notification

Right now, we URL-encode some args to the iconURL to pass data to the
handler function that is registered via
navigator.mozSetMessageHandler('notification', function(){}) [1].

It would be better if I could just pass a JSON-friendly data object to
Notification instance and then have access to that data in the
notification callbacks that are triggered.

We cannot depend on notification.onclick to work since the app can be
closed after the notification is fired. It also seemed very unreliable
to depend on it, given garbage collection possibilities. So we cannot
reliably capture state using a function closure.

2) General notification callback entry point

We are avoiding use of notification.onclick/onclose and would prefer
to have a generic entry point to receive notification events. Right
now we use navigator.mozSetMessageHandler('notification',
function(){}).

but I would prefer to see a more official entry point in the spec. I
would go so far as to want to deprecate the .onclick and .onclose as
in practice they are not reliable, given that the app may be closed
down after firing the Notification but before it is clicked.

3) onclick fires onclose too?

It seemed a bit unclear in the spec, but right now FirefoxOS fires
onclose too for onclick actions, as the onclick pathway removes the
notification from the list of notifications.

This seems counterintuitive to me, I would have only expected one
event. Perhaps clarifying the onclick behavior would be good.

I would prefer to just see one event fired in this case, if
onclick/onclose are kept around. If the general notification callback
entry point is established, then just firing it once with the
event.clicked property set to true for the clicked route.

4) onclick does not bring web app to front

This may be part of just further defining the steps for the "click"
pathway in the spec, but at least in FirefoxOS right now, the
notification onclick pathway does not bring the app to the visible
front in all cases. The email app has to do some extra document.hidden
checking and try to bring itself to the front.

What I would rather see is by default the web page is brought to the
visible front, and then perhaps allow the app a way to cancel that
behavior perhaps via a preventDefault() type of mechanism on any
notification click event.

This would also reduce the need for an API that the app could call to
bring itself "to the visible front". Right now, there is an
app.launch() API in FirefoxOS for this, but there are concerns that
giving apps the ability to launch themselves to the front could lead
to an abuse of that API.

5) Ability to set notification modes.

This one is a bit less defined. I would rather this one is discarded
than spending too much time on it if it meant losing track of the
points above:

For email notifications, we did not necessarily want the phone to
light up the screen on every notification and make a sound or vibrate
(particularly at night), but rather just register the notification and
have it show up in the notification count and listing.

While ideally there is UI for the user to control notification
behavior for all web apps, I can also see the case for allowing
notifications the ability to opt in to the notification modes it
prefers.

Any user settings would override the modes specified in the
notification, but for apps that did want to be nice, it would be a way
to avoid a very annoying first notification behavior, in the case of
email, not disturbing the user unless they did an explicit override.

This may be too tricky to specify, but I started a bugzilla bug for
FirefoxOS for this[2]. One suggestion was listing the preferred modes
in the web app manifest, but I can see an app may have different types
of notifications, so it would be more flexible to set per Notification
instance.

There is a dev-gaia thread[3] that prompted this feedback.

[1] https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.mozSetMessageHandler

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645

[3] https://groups.google.com/forum/#!topic/mozilla.dev.gaia/NVacmcxGt2Q

James