[whatwg] Notifications: usage feedback

[James Burke]

On Fri, Sep 27, 2013 at 12:54 AM, Andrew Wilson <atwilson at google.com> wrote:
> 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.

Hopefully the mobile focus of FirefoxOS points to likely issues for
any browser on mobile.

For example, I can see where it will be common for mobile browsers to
do some sort of web page quiescence, even a full close, maybe just
saving a screenshot of the tab, for memory concerns, even if the user
still considers the tab "open". I expect the majority of browser use
over time will fit into devices that fit the "mobile space" definition
vs desktop space definition.

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

An URL could work too (our hack right now is to attach data to the
imageURL for the notification and read that data), but I still I
prefer using a data object for the data of the notification.

The notification object could have an URL associated with it, and the
browser would open the URL if it did not already have a tab/process
for it, then send a data message to it, but if the URL was already
open, just send a data message to it with the notification object.

In that approach the URL would not have querystring args, and the
browser would match the URL to the URLs of existing opened tabs/apps,
but without the query string or fragment ID to find a match. This
would allow an already open page to handle multiple notification
clicks via an entry point message handler discussed in the first post
on this thread.

In the cases of memory conscious browsers, it could rehydrate the tab
that was currently tracked for that URL, and it would still work
without needing to maintain closure state as compared to the
notification.onclick/onclose route currently specified.

James