[whatwg] Notifications: in workers

[Andrew Wilson]

On Tue, May 14, 2013 at 9:19 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Tue, May 14, 2013 at 8:51 AM, Andrew Wilson <atwilson at google.com>
> wrote:
> > On Sun, Mar 31, 2013 at 4:40 PM, Anne van Kesteren <annevk at annevk.nl>
> wrote:
> >> This seems problematic for shared workers as it is not clear which
> >> window the notification would be for. For normal workers this seems
> >> like less of a concern.
> >
> > Not sure what you mean - why does it matter which window the
> notification is
> > for? Maybe this is only important for the permission prompt, but not for
> the
> > notifications themselves which live outside any specific window?
>
> Chrome currently does not seem to do any of this particularly well,
> but when you click a notification from say the notification center
> there should be some "going to the relevant site" going on. E.g. via
> focusing a particular browsing context that spawned the notification.
>

I'm not sure that's true - as I said, the specification says nothing about
this, and the page that displays the notification is free to focus itself
via an onclick handler if it likes.

As an example, if you click on a gmail new-mail notification, instead of
focusing gmail (which might be in the middle of some other operation such
as composing an email, or you might be viewing a different message thread)
we open the associated email in a new window. So in this case, we actively
do *not* want to focus the source browsing context.

So the chrome behavior is intentional.


>
> We also want to enhance the API to support the scenario of the site
> being closed but the notification still being alive, with the
> notification being able to revive the site in some way and the site
> being aware which notification was clicked (note that currently it
> would no longer have a reference to that object).
>
>
> >> If we go with the idea of exposing a URL on Notification objects and
> >> allow that to be set we might be able to address the shared worker
> >> issue, but it is not entirely clear to me which semantics are
> >> desirable there.
> >>
> >> Maybe if we made it a URL prefix it could work. E.g. you create a
> >> notification with a URL http://example.org/mail/ If that origin is
> >> allowed to display notifications that will all go well.
> >
> > SharedWorkers already have an inherent domain, inherited from their
> creating
> > documents, correct? Why would we need to specify one when creating
> > notifications?
>
> Trying to brain storm as to what should be done when you click a
> notification of a site that is no longer there. Navigating to a URL
> was one idea. Starting up an event worker as outlined (roughly) in
> http://annevankesteren.nl/2013/05/applifying might be a better idea.
>
>
That's not a bad idea - as you know from my separate email with you, I'm
less enamored with using Workers for these kinds of on-demand/background
footprint tasks, because they are limited in so many ways (can't display a
visible browsing context, for example). I prefer having instead a page that
is loaded off-screen, albeit perhaps with a limited lifetime as you
describe in that page.


> > Not sure what you mean - are you expecting clicks on a notification to
> focus
> > the initiating window (I don't see this behavior described in the
> > notification spec)? Typically, this would be done via an onclick()
> handler,
> > so in that case it would be up to the SharedWorker to proxy that event
> to a
> > window if it wanted to focus one and not something the browser itself
> would
> > do.
>
> Yeah, that's currently not described. You think we should leave that
> to developers? That might work, although that leaves the questions
> about the site being closed.
>

Yeah, it does. Currently in Chrome we basically punt on this, with the
expectation that well-behaved pages close their notifications via an
document.onclose handler. I hadn't really considered the case of the app
developer wanting their notifications to hang around after the window
closes and still have some action undertaken when the user clicks on them.


>
>
> > I feel like I'm misunderstanding the proposal though - sorry if I'm
> missing
> > some context here.
>
> No worries, your input is much appreciated :-)
>
>
> --
> http://annevankesteren.nl/
>