Re: [whatwg] Notifications improvements

On Thu, Jul 10, 2014 at 8:01 AM, Peter Beverloo <beverloo@google.com> wrote:
>
> On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> We need to change the GC behavior. Right now it seems like if a
>>
>> Notification object is created, but no event listeners are attached,
>> because the page is expecting to use the SW event to listen for
>> clicks, the notification won't be kept alive and so the SW can't get
>> to any of its data.
>>
>> We also need to keep state on the Notification object if the user has
>> clicked the notification or not.
>>
>> We should also consider enabling passing a URL to the Notification
>> constructor which is opened when the user clicks the notification.
>> Probably this should attempt to reuse an existing tab with said URL if
>> one is open.
>
>
> Notifications should just be serialized and re-created on demand, since they
> can outlive both pages and workers.
>
> If a page creates a notification, events for which should be delivered to a
> Service Worker, then won't be able to re-use the existing object anyway. We
> can't rely on a SW to stay alive between [creating a notification,
> interacting with the notification] either. Since the |data| property exists,
> developers can use that (or the notification's title) instead of using the
> equality operator.
>
> I believe we had some discussion about a launch URL earlier on. There are
> various race conditions: what if the user presses twice on the notification
> in quick succession - will we open the page twice? What is a page with that
> URL has already been opened? What if there are two? Deferring to a Service
> Workers solves these. The |notificationclick| event could be allowed to open
> windows, too.

I completely agree. The spec needs to separate the notion of a
UI-visible notification, from the Notification object instance.

/ Jonas

Received on Friday, 11 July 2014 00:33:08 UTC