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

Re: [whatwg] Notifications and service workers

From: Peter Beverloo <beverloo@google.com>
Date: Wed, 1 Oct 2014 13:56:57 +0100
Message-ID: <CALt3x6ks_LYSGmwMfOcXQsmeNrrZZyJ0Jeoee8HkvsM5ZvqP0w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Andrew Wilson <atwilson@google.com>
On Wed, Oct 1, 2014 at 12:31 PM, 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.
>
>
> > * 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.
>
>
> > * 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.
>

It could just be an accessor on the ServiceWorkerRegistration for both
convenience and consistency, mapping to the constructor with the
serviceWorker property set. We'll need to keep the constructor in either
case.

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

One argument I came across for overloading requestPermission is the
following:
    Promise.all([ Notification.requestPermission(),
swRegistration.push.requestPermission() ]).then(...);

Might be worth considering, it's relatively cheap to support and can be
implemented without breaking backwards compatibility.

Thanks,
Peter


>
>
> --
> https://annevankesteren.nl/
>
Received on Wednesday, 1 October 2014 12:57:25 UTC

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