[whatwg] Notifications: usage feedback

[Andrew Wilson]

So, I'm not entirely sure how many lessons taken from the FirefoxOS
implementation are applicable to the API for web pages in general, but I
agree that "what do we do if the user clicks on a notification after the
parent page has been closed" is a bit of an unsolved/unsolveable problem
with the current API.

I dimly recall seeing an email thread proposing adding some kind of click
URL to a notification (and my search-fu is not strong enough to find a link
to it, sadly), which seems like it would address some of the issues you
have with the current API (encoding data that can be passed back to the app
on a notification click, even if the app has been closed in the meantime).
The solution I've seen implemented on the web (shutdown notifications when
a web page is closed) clearly doesn't work for a platform like FirefoxOS
which does memory management and app shutdown behind the scenes.


On Fri, Sep 27, 2013 at 3:15 AM, James Burke <jrburke at gmail.com> wrote:

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