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

One amendment to (3), which events to expose on the
ServiceWorkerGlobalScope, is that we should only expose the
|notificationclick| and |notificationclose| events.

The benefit of not exposing |notificationerror| is that there are two
situations in which we would fire the event: (a) when there is no service
worker, and (b) when there is no permission. Both are known shortly after
creating the Notification object (but not synchronously). This avoids
confusion about where to listen for errors.

For |notificationshow|, there is a worry here that if we decide to support
delayed notifications, it would enable developers to use notifications to
set precise timers: create a delayed notification to be displayed an hour
from now, get the |notificationshow| event, and call
|notification.close()|. This is something which I'd hope would only be
possible through some kind of alarms API, which in itself may be
undesirable to start with.

Thanks,
Peter


On Tue, May 13, 2014 at 3:33 PM, Peter Beverloo <beverloo@google.com> wrote:

> 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 Thursday, 15 May 2014 16:13:21 UTC