[whatwg] Notifications: in workers

[Anne van Kesteren]

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.

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.


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


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