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

Re: [whatwg] Notifications and service workers

From: Andrew Wilson <atwilson@google.com>
Date: Tue, 30 Sep 2014 09:48:51 +0200
Message-ID: <CAArhhiuiNtO39-bi5wOx3-scK2FKpYdOw_SF2vmzisUW9o58NA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Robert Bīndar <robertbindar@gmail.com>, Peter Beverloo <beverloo@google.com>
On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

My test on mac and linux chrome just showed that notifications never close
on those platforms.
Received on Tuesday, 30 September 2014 07:49:17 UTC

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