- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 7 May 2009 21:47:04 +0000 (UTC)
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.) > 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 14:47:04 UTC