386823 - XMLHttpRequest gets wrong principal if no JS on stack

Status: RESOLVED FIXED

(Core :: XML, defect, P4)

Description

[Peter Van der Beken [:peterv]]

Follow-up to bug 386656 (see bug 386656, comment 6). We should do the equivalent of what bug 332840 fixed for DOMParser.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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....

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sounds like the nsIJSNativeInitializer setup DOMParser uses would work, at least if the |cx| there is windowB in the above case.

Comment 4

[Anne (:annevk)]

Also note that URI resolving happens on open(), not send(). (Including security exceptions.)

Comment 5

[Johnny Stenback (:jst)]

Better safe than sorry :) Blocking on this, should be pretty straight forward.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In bug 372964 XHR gets always bound to a window)

Comment 7

[Boris Zbarsky [:bzbarsky]]

That's not reasonable for JS components.  No windows there.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

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).

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

I assume we want here something smaller than bug 372964, something less riskier, like bug 332840?

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

C++ callers would then be responsible for initializing with the window and principal.

Comment 13

[Boris Zbarsky [:bzbarsky]]

What sicking said, absolutely.

Comment 14

[Johnny Stenback (:jst)]

FIXED per Jonas...

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed by the patch for bug 392322, to be exact.

Comment 16

[Daniel Veditz [:dveditz]]

Do we need this one on the 1.8 branch as well?