On Sun, 31 Mar 2013 16:40:16 +0200, Anne van Kesteren <ann...@annevk.nl>
wrote:
There is some interest in exposing Notification objects in a worker so
creating one does not require a postMessage() roundtrip.
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.
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.
My knee-jerk reaction is to tie it to MessagePorts, so that if you make a
notification on a port, the window that owns the entangled port displays
the notification. If there isn't an entangled port or if it's not in a
window, I guess it could silently fail.
The above would enable making notifications from one window on behalf of
another window, if there's a message channel between the two.
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. If there's a
window open with that URL as prefix it can be focused once the user
activates the notification. If there's no window open a window can be
opened with that URL (no longer a prefix in this scenario). However,
if there's several windows with that URL it's not clear what the best
way would be. The last window the user interacted with maybe?
--
http://annevankesteren.nl/
--
Simon Pieters
Opera Software
