[whatwg] [Notifications] Persistent notifications depending on Service Workers

Based on Anne's Reviving Notification Objects thread from last year, I
would like to propose an alternative solution.


http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/251058.html

There are known lifetime issues with Notifications, and rather than tying
them all to the page, how about considering event delivery to a Service
Worker instead? This solves (a) the case in which the tabs are no longer
available, (b) the case where multiple tabs with the "launch URL" have been
opened, and (c) the case where the user clicks on several notifications
before the page load is complete.

Concretely:

    (1) Extend the NotificationOptions interface with a serviceWorker
property. When set to true, event delivery will *only* go to the Service
Worker. However, we should probably still fire |onerror| when no service
worker is current for the page.

    (2) Extend the Notification interface with the serviceWorker property,
as a read-only boolean. For browsers which correctly expose properties on
the prototype chain[1], this can therefore be feature-tested using
Notification.prototype.hasOwnProperty('serviceWorker').

    (3) Extend the ServiceWorkerGlobalScope interface[2] to define
|notificationactivate| and |notificationshow| events. Both receive a
NotificationEvent object, which exposes a |notification| property providing
access to (a clone of) the relevant notification.

I don't have a strong opinion on whether we should have a
|notificationclose| event in the SW scope. It could be useful for a
background music player, in which dismissing the notification stops
playback (through a postMessage to an open tab, supposedly).

In the future, the NotificationActivateEvent property could be extended to
include information from rich features, e.g. |button|, if we decide to take
that route.

Thanks,
Peter

[1] Chrome bug: http://crbug.com/43394

Received on Tuesday, 13 May 2014 14:34:24 UTC