Re: [whatwg] Notifications and service workers

On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson <atwilson@google.com> wrote:
> OK, looked back into the Gmail code (since it'd been a couple of years since
> I was really down in that notification code). There are two places where we
> listen for close events currently:
>
> 1) When closing an email notification - gmail keeps its own queue of pending
> notifications (so if several emails arrive at once, we don't display seven
> notifications simultaneously, but instead we display one at a time, cycling
> through them after 5-6 seconds). If the user closes a notification, then we
> clear out our queue of pending notifications, because the expectation is
> that the user doesn't want any more email notifications (the experience
> before we did that was really annoying).

Ah, so the fact that the user close one notification is seen as an
indicator that the user doesn't want more notifications right now.

This definitely seems like the best use case for the "close" event so
far. Though it doesn't seem like you'd actually want a service worker,
or indeed the full app, to be started up in order to handle that
event.

For an app that wants to do something like this, but the app uses
persistent notifications, I think using Notification.get() is the best
solution. This way the application can catch closing of notifications
whenever they happen, but the app still doesn't need to be woken up if
it's not running when a notification is closed.

For an app that uses non-persistent notifications, such as gmail, I
think we have two options. Either use Notification.get() here too. Or
we allow "close" events to be fired for non-persistent notifications.

> 2) When closing a chat notification, we tell the chat subsystem that the
> notification has gone away so that it can clear its reference to the
> Notification. The chat subsystem keeps a reference to the notification so it
> can close a chat notification if the user clicks on a chat frame, but this
> might no longer be necessary if we implement Notification.get(). Anyhow, our
> reference to the chat subsystem is a reference to an object and that object
> isn't structured-cloneable because it has a bunch of reference to DOM
> elements, etc.

Interesting. Yeah, Notification.get() seems like it would help you
solve this. Though potentially the API should also have a function
like Notification.close(DOMString tag). Seems like a common use case
of wanting to close a notification when the user engages with a piece
of UI, and it seems silly to have to instantiate a Notification
instance through .get() to do so.

> The other reason we handle the close event is that gmail has this idea of a
> chat notification that the user hasn't seen yet - the chat frame has a
> visual highlight. But if the notification is dismissed by the user, we can
> clear this highlight, under the assumption that the user has seen this
> notification. This functionality may be somewhat broken on platforms that
> auto-close notifications though.

Yeah, this is the case that Jake brought up. Though Tab pointed out
that other chat systems generally does not treat "close" as an hint
for "user has read". Interesting to hear that gmail does.

On what platforms do non-persistent notifications not close after a timeout?

/ Jonas

Received on Monday, 29 September 2014 19:15:52 UTC