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

Re: [whatwg] Notifications and service workers

From: Andrew Wilson <atwilson@google.com>
Date: Mon, 29 Sep 2014 15:09:25 +0200
Message-ID: <CAArhhisdmciPLz77vaCU-+tMd+-9omJFT9n+e5mcNsf=RqUUFg@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>
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).

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.

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.

On Mon, Sep 29, 2014 at 2:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson <atwilson@google.com>
> wrote:
> > On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson <atwilson@google.com>
> >> wrote:
> >> > I'm sorry, I meant that you can only use the 'data' attribute, if the
> >> > data
> >> > you want to associate with the notification is structured-cloneable.
> >> > Which
> >> > precludes lots of interesting stuff, like objects with attached
> methods,
> >> > memoized functions, etc.
> >> >
> >> > I'm aware that 'data' is structured-cloneable - I'm saying that's not
> >> > sufficient for many uses.
> >>
> >> But if the data that you want to associate with the notification isn't
> >> structured clonable, how are you going to make that data survive a
> >> page reload? Keep in mind that for persistent notifications, the
> >> notification often outlives the page that created the notification.
> >
> > OK, I get it - we're talking about different models. I'm talking about
> the
> > current Gmail use case, where I don't want notifications to live forever
> (in
> > fact, I close them all when you close the main Gmail pane).
> >
> > I understand that for persistent notifications, the uses are different.
> And
> > again, apologies if I missed the context and the idea was to only remove
> the
> > close event for persistent notifications - it's the danger of dropping
> into
> > the middle of a thread :) Hopefully the plan is to continue enabling web
> > properties that want to go the Gmail route to continue doing so, and for
> > those pages, I think a 'close' event is useful.
>
> I think we're talking about both. But I wanted to point out that the
> code flow you were talking about didn't seem to work for persistent
> notifications.
>
> I'd rather keep persistent and non-persistent notifications as similar
> as possible. Though "as possible" being key. I.e. I think it's ok for
> them to be different when that makes sense.
>
> I still don't understand the use case you are talking about though.
> Could you perhaps provide an example of the features that gmail is
> building and which needs these non-clonable data structures?
>
> / Jonas
>
Received on Monday, 29 September 2014 13:09:59 UTC

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