Re: [whatwg] Notifications and service workers

On Wed, Oct 1, 2014 at 4:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo <beverloo@google.com> wrote:
>> * Life-time of existing notifications.
>>
>> Chrome currently treats Web Notifications as "persistent" ones. When the
>> page goes away, the notification stays. Interaction with the notification is
>> not going to trigger anything anymore. While I'm in favor of changing this,
>> we have to be very cautious to not break user expectations of existing users
>> of the Web Notification API, for example in calendar applications.
>
> I think from the perspective of the specification this does not change
> anything. If a platform wants to log all notifications that is fine.
> What we want to start calling "persistent" notifications are those for
> which a service worker will get notified and which can be retrieved
> using Notification.get(). Hopefully browsers and platforms evolve over
> time to distinguish the two more clearly.

As long as all implementations are willing to change |new
Notification| to be non-persistent then that's fine. Note that
non-persistent is different from "doesn't fire a callback when
clicked". While JS running in the page can't tell a difference, the
user certainly can so it can still be perceived as a breaking change.

>> * Dropping the close event.
>>
>> Synchronizing closing of the notification on all the user's devices is an
>> interesting one, but opt-in would be sufficient for this.
>
> Yeah, it seems like we need to keep this. Through opt-in works.

It seems like if we keep this event it should at the very least be
possible to tell "closed because of user action" from "closed because
of timeout or other platform policy". And maybe also "closed because
of application calling .close()". Otherwise it doesn't seem like it
meets Andrew's use case or the use case above.

>> * Not using the constructor for persistent notifications.
>>
>> I have no strong feelings here either, and think it's fine to continue using
>> the constructor with the serviceWorker property set. Both would still use
>> the Notification statics. Having a promise would clean up the error handling
>> a bit, which may occur in the no-permission case.
>
> It seems nicer to have the association with the registration be
> implicit by having a method on that object (reg.createNotification()).
> However, it's very much the factory pattern which is somewhat frowned
> upon. But hopefully it's not too bad here.

Note that I don't actually think that we need to even return a
Notification instance when a persistent notification is created.
There's no events being fired on such a Notification instance and it
doesn't provide any other functionality. It only contains the
information that was just passed to the createNotification call.

So it wouldn't even be a factory method if we simply don't return a
Notification.

> Combined with dropping the open event, I think I have enough to rework
> the current Notifications API. Is there anything I'm missing?

I think this covers the basic changes needed to enable proper support
for persistent vs. non-persistent notifications, which is a big
improvement.

But I think there's also a lot of additional features that are needed,
but that's probably better done separately. Especially since that has
less consensus I believe. I'm thinking of things like buttons,
progress bars, extra-persistent notifications, control over sound
and/or vibration, control over whether it turns on the screen, text
input, etc.

But at the very least these warrant separate threads.

/ Jonas

Received on Saturday, 4 October 2014 03:00:47 UTC