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

Re: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note

From: Andrew Wilson <atwilson@google.com>
Date: Wed, 23 Apr 2014 16:09:45 +0200
Message-ID: <CAArhhit+4rDCowR4rnxwYt7u4grHCwGKXC3W7p7U0HYW1AQ=YQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: whatwg <whatwg@lists.whatwg.org>, Edward O'Connor <eoconnor@apple.com>
The problem here is that the platform's notification design has no way to
understand what the application wants to happen when the user clicks on a
notification.

As a great example - Gmail uses desktop notifications to notify the user
about chat events and new emails. When the user clicks on a chat
notification, gmail uses window.focus() to focus itself so the user can
view the chat (which is displayed in the main gmail window via a <div>
overlay).

When the user clicks on an email notification, we don't want to bring up
that email in the main gmail window because the user may be in the middle
of some other operation (like composing an email) - in fact, we don't want
to focus the gmail tab at all. Instead we pop up that email in a separate
popup window. In that case, having the UA auto-focus the tab is a mistake.

I'm OK if you somehow want to make auto-focus a default property of the
notification and have the app determine a-priori whether a given
notification should trigger auto-focus at the time the notification is
created, but it seems less flexible than the current behavior that Chrome
has, which is that notifications don't auto-focus, and that applications
have full control over what they want to happen when a click occurs.

I suppose you can make the argument that auto-focus is so overwhelmingly
common that we should just make it the default as a developer convenience -
do you have any data to back up this assertion?
In any case, I'm OK with the status quo, which is that UAs either
auto-focus (if they want to force consistent click-on-notification
functionality regardless of app intent) or they should support
window.focus(). Actively prohibiting window.focus() seems like a bad step.

-atw


On Thu, Apr 17, 2014 at 1:45 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Apr 16, 2014 at 6:10 PM, Edward O'Connor <eoconnor@apple.com>
> wrote:
>
> > Hi,
> >
> > In 4.6 Activating a notification, there's a note that currently reads
> >
> >     "User agents are strongly encouraged to make window.focus() work
> >     from within the event listener for the event named click as a means
> >     of focusing the browsing context related to the notification."
> >
> > This note assumes that the UA doesn't automatically focus the browsing
> > context when a notification is activated. (Safari on OS X is one example
> > of a UA which does this.) The note should be adjusted so that readers
> > understand that calling window.focus() may not be necessary on some
> > combinations of UA and system notification service.
> >
>
> Rather, pages should never be allowed to window.focus() when a notification
> is activated.  If the platform's notification design wants that to happen,
> it's the platform's job to do that, and pages shouldn't all be required to
> call window.focus() to make this happen consistently.  (If for some reason
> the platform doesn't want that to happen, the page shouldn't be able to
> override that, either.)
>
> If there are notifications that don't want to focus a page when activated,
> that should be a setting on the notification.
>
> --
> Glenn Maynard
>
Received on Wednesday, 23 April 2014 14:10:13 UTC

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