Follow-up to bug 386656 (see bug 386656, comment 6). We should do the equivalent of what bug 332840 fixed for DOMParser.
Except we should check what the XMLHttpRequest spec says about cross-window XMLHttpRequest() constructors. And whether what send() does depends on the calling window or where the request was constructed. Ideally, imo, we would grab all the security stuff once: at construction time. And nix the script context business we have around there....
iirc the spec says to use the scope of the ctor that was used. So doing, in windowA, |new windowB.XMLHttpRequest()| would create an XHR with base and principal of windowB.
Sounds like the nsIJSNativeInitializer setup DOMParser uses would work, at least if the |cx| there is windowB in the above case.
Also note that URI resolving happens on open(), not send(). (Including security exceptions.)
Better safe than sorry :) Blocking on this, should be pretty straight forward.
(In bug 372964 XHR gets always bound to a window)
That's not reasonable for JS components. No windows there.
I know that is a problem. From the current XHR WD: "When the XMLHttpRequest() constructor is invoked a persistent pointer to the associated Window object must be stored on the newly created object. This is the Window pointer. The associated Window object is the one of which the XMLHttpRequest constructor was invoked. This pointer must persist even if the browsing context in which the Window is located is destroyed (by removing it from a parent browsing context, for instance). " So unless the spec changes, we'll have to bind xhr to window in the normal case, when xhr is used in web pages. For C++ or JS Components something else is needed. Like the Init method from bug 332840 :) (bug 372964 adds an Init method to XHR too, though, probably that should take different parameter).
Oh, sure. That sounds good, yeah. As long as everything we need off the window can be provided in some other way, life is good.
10 years ago
What we should do here is to do what the XHR spec says and initialize the XHR with a window (and principal) when created. We can then use that principal always rather than constantly looking for a JS-stack whenever we need a security context or similar.
C++ callers would then be responsible for initializing with the window and principal.
What sicking said, absolutely.
FIXED per Jonas...
Do we need this one on the 1.8 branch as well?