Re: [whatwg] Notifications and service workers

On Thu, Sep 25, 2014 at 3:25 AM, Jake Archibald <> wrote:
> On 24 September 2014 01:21, Jonas Sicking <> 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.


>> * 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?

Do implementations really treat them as non-persistent? In FirefoxOS
we treat them as persistent. In Firefox for Android we put them in the
Android notification tray, where generally only persistent
notifications go I thought. And indeed we don't have any code to
automatically remove them.

But I don't know what other implementations do?

>> * 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

Hmm.. is "close" really a decent proxy for "read"? I personally often
read notifications without clearing them, since I read the temporary
on-screen notification. And on occasion when my notification tray
overflow, I clear notifications without reading them.

But I hate using my own usage patterns in design. Do we have any data
on what native applications do with similar callbacks? Assuming they
exist in other notification platforms...

>> > 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).

I'd really not want to use "all" as a default. That will result in us
starting service workers much more often than we need, which at best
is a battery drain, at worst is a performance issue.

/ Jonas

Received on Thursday, 25 September 2014 23:25:04 UTC