- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 07 May 2009 15:12:01 -0700
On May 7, 2009, at 2:47 PM, Ian Hickson wrote: > On Thu, 7 May 2009, Drew Wilson wrote: >> >> Having MessagePorts in worker context means that Workers can outlive >> their parent window(s) - I can create a worker, pass off an entangled >> MessagePort to another window (say, to a different domain), then >> close >> the original window, and the worker should stay alive. In the case of >> WebKit, this causes some problems for things like worker-initiated >> network requests - if workers can continue to run even though there >> are >> no open windows for that origin, then it becomes problematic to >> perform >> network requests (part of this is due to the architecture of WebKit >> which requires proxying network requests to window context, but >> part of >> this is just a general problem of "how do you handle things like HTTP >> Auth when there are no open windows for that origin?") > > How does WebKit handle this case for regular Windows? (e.g. if a > script > does x=window.open(), grabs the x.XMLHttpRequest constructor, calls > x.close(), and then invokes the constructor.) I believe what would happen is: the UI would be thrown up by the window in which the script doing x.XMLHttpRequest runs, rather than the home window. - Maciej > > >> The thing we'd give up is the capabilities-based API that >> MessagePorts >> provide, but I'd argue that the workaround is simple: the creating >> window can just act as a proxy for the worker. > > That's a rather poor workaround. :-) > > -- > Ian Hickson U+1047E ) > \._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _ > \ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'-- > (,_..'`-.;.'
Received on Thursday, 7 May 2009 15:12:01 UTC