- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 30 Sep 2014 01:15:33 -0700
- To: Drew Wilson <atwilson@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jake Archibald <jaffathecake@gmail.com>, Robert Bindar <robertbindar@gmail.com>, Peter Beverloo <beverloo@google.com>
On Sep 30, 2014 12:48 AM, "Andrew Wilson" <atwilson@google.com> wrote: > > > > 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. I guess I don't know enough about the ins and outs of osx notifications. But all my other osx apps remove notifications after a few seconds. But it is of course chrome's choice what UI to display. In any case it sounds like gmail would not notify properly on platforms where notifications do dissappear after a few seconds, which seems problematic, no? / Jonas
Received on Tuesday, 30 September 2014 08:16:00 UTC