[whatwg] Notifications: in workers

[Andrew Wilson]

On Thu, May 16, 2013 at 5:45 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Wed, May 15, 2013 at 8:24 AM, Andrew Wilson <atwilson at google.com>
> wrote:
> > On Tue, May 14, 2013 at 9:19 PM, Anne van Kesteren <annevk at annevk.nl>
> wrote:
> >> 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.
>
> Fair enough.
>
>
> >> 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.
>
> So how would that work if open gmail.com twice, in two distinct
> browsing contexts? Long term we want those to be able to use distinct
> threads I think, but they should be able to share a single event
> page/worker.
>

I'll have to ping the gmail team to ask what they did there in their
prototype.


>
> Not having the ability to focus (draw attention to) and open windows
> does seem like something we should solve. (The cross-origin loading
> case you mentioned should really be solved using WebSocket or CORS. I
> heard from at least one guy from your app team that they want to move
> to something like that long term and the <iframe> thing is mostly a
> intermediate hack.)
>
>
The <iframe> thing (and other <script>-based solutions like JSONP) are
definitely hacks, but they are hacks with a fairly long history in the web
world. Agreed about CORS, although we've been talking about CORS support in
workers for a while now with no implementations AFAIK - maybe we just need
a compelling feature like this to drive teams to actually build it.

Agreed that there's nothing stopping us from building whatever APIs we
think we need into workers (window.open, window.focus, etc) to support the
use cases that are already supported by the main browsing contexts, if
there's a compelling reason to use workers instead.


>
> >> 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.
>
> That seems like something we want to support, no? E.g. you get a push
> message, so you open the event page/worker, and that dispatches a
> notification, but then you want to kill the event page/worker so it
> doesn't continue to use system resources. Couple days later the user
> might click the notification and then you'd open the event page/worker
> again.
>

Agreed, I think this is a valid use case once you support event
pages/workers as targets for notifications (it also probably has some uses
for things like server-initiated notifications, where the server can
specify a URL to navigate to when the user clicks, although I've never
really paid attention to the server-initiated notification discussions so I
don't quite follow their use cases).


>
>
> --
> http://annevankesteren.nl/
>