[whatwg] Notifications: in workers

[Anne van Kesteren]

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.

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.)


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


--
http://annevankesteren.nl/