- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 03 Apr 2013 08:50:29 +0200
- To: WHATWG <whatwg@whatwg.org>, "Anne van Kesteren" <annevk@annevk.nl>
On Sun, 31 Mar 2013 16:40:16 +0200, Anne van Kesteren <annevk@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
Received on Wednesday, 3 April 2013 06:51:17 UTC