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 10:26:48 +0200
Message-ID: <CAArhhisDm-Mw2g9qTj=KkCgLRts_YN5hUxS0EL6FogVXh3P6tA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
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 Tue, Sep 30, 2014 at 10:15 AM, Jonas Sicking <jonas@sicking.cc> wrote:

>
> 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.
>
Chrome on OSX isn't using the native notification framework (at least, not
on my laptop).

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

I think that Chrome doesn't generate a close event in the case that the
notification is hidden, but agreed, it's a problem. It's frankly one of the
major flaws of the original spec that behavior like this isn't well
specified, because it really prevents applications from doing anything
particularly sophisticated around notification management, because you
can't keep notifications on-screen if the notification platform wants to
close them, and you can't easily differentiate between user-close and
system-close.

The thing to remember is that gmail's notification functionality was
written back when Chrome was the only browser that supported notifications,
and there were no system notification platforms (at least, none that were
used by any UAs). So some of the behavior in Gmail only makes sense on
platforms where Chrome's original notification functionality still holds
(i.e. chrome on linux/mac). It still works "well enough" on other platforms
(modulo bugs in some edge cases where there are multiple email
notifications at once) that nobody has gone in to rewrite the functionality.
Received on Tuesday, 30 September 2014 08:27:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:31 UTC