Re: [whatwg] Notifications and service workers

On 24 September 2014 01:21, Jonas Sicking <jonas@sicking.cc> wrote:

> * Notifications that close when a page goes away does not seem useful
> on mobile, but could be useful on desktop to enable minimized
> applications, or applications whose window is covered by other
> windows, call attention to themselves.
>

I agree with Tab regarding track change. But more than that, we shouldn't
be making a platform distinction here, that may not hold true in a few
years.


> * For persistent notifications, in cases where the application cares
> about the user clicking on the notification (as opposed to
> fire-and-forget notifications), we should always send a notification
> to the service worker. In this scenario it never seems useful to fire
> an event on the Notification instance since that will just mean
> multiple codepaths trying to handle the same click. At best that would
> be wasted performance, at worst it could mean broken UI or application
> logic.
>

Totally agree, I didn't realise this was possible in the original proposal.
The option that makes it a persistent notification should retarget all
events to the serviceworker. If the serviceworker is invalid, I guess we
throw?


> * I'm uncertain about if non-persistent notifications are important
> enough to target at this point. But I'm heavily biased from having
> worked mainly on mobile web lately.
>

Not sure what you mean here. Aren't non-persistent notifications fully
shipped and supported?


> * Alternatively, maybe we could simply get rid of the "close" event
> entirely. Does it have a use-case?
>

Yeah:

* User gets new chat message
* Push message
* Notification
* User reads chat message but doesn't need to respond, dismisses
notification
* Close event
* Message sent to the server to make message as "read"
* Notifications auto-dismissed on other devices the user has

On 25 September 2014 11:02, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> Strawman: We classify existing notifications as non-persistent
> >> notifications. Only notifications associated with a service worker are
> >> persistent.
> >
> > This is a little bit implicit for my taste. But I don't feel very
> strongly.
>
> I think it makes a lot of sense if we require service workers for
> persistent notifications. I figured we could rename the field from
> serviceWorker to something more explicit, but I can't really think of
> a good name.
>

eventTarget: serviceWorkerRegistration

persistWith: serviceWorkerRegistration


> That means we should tie normal non-persistent notifications to the
> lifetime of the global. I take it we still want to allow those within
> workers, right?
>

The ServiceWorker default would be persistent though right? Creating a
non-persistant notification in a ServiceWorker is likely to go wrong as you
lose your event handers when the worker terminates.


> > But maybe they are rare enough that by default we only fire "click"
> > events. For persistent notifications we fire them at the SW, for
> > non-persistent at the Notification object.
> >
> > If we in the future find actual use cases for "close"/"show" we can
> > add ways to opt in to receiving those. And if we find use cases for
> > *not* receiving "click" (in particular to SW) we can add ways to opt
> > out of those.
>
> This strategy makes sense to me. If Jake and Peter (and everyone else
> who feels inclined :-)) could comment on this revised proposal that'd
> be great.
>

I don't have a use-case for "show" right now, but I think we need to keep
"close" for the use-case above. An events property could take an array to
restrict the events a notification will fire (defaulting to all).

Received on Thursday, 25 September 2014 10:26:09 UTC