W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

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

From: Peter Beverloo <beverloo@google.com>
Date: Tue, 13 May 2014 16:33:59 +0200
Message-ID: <CALt3x6mHaTbeV9hX-4LEmD6m4_iBhjat_sYDdGCFNyfFbKtoyw@mail.gmail.com>
To: whatwg@whatwg.org
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC