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. `._.-(,_..'--
(,_..'`-.;.'
