When using expanded principal list in sandboxes, XMLHttpRequest throws an NS_ERROR_FAILURE exception. Here is a minimal testcase that can be run in scratchpad: let Cu = Components.utils; // Use new feature from bug 734891: let s = Cu.Sandbox([content.location.href, "http://bar.com"]); s.window = content; let js = "(" + function () { try { // This line is throwing: return window.XMLHttpRequest(); // Can test this form too when you get a patch, // As we are using this more complex pattern in jetpack: return Function.prototype.apply.apply( window.XMLHttpRequest, [window, []] ); } catch(e) { return e; } } + ")()"; let r = Cu.evalInSandbox(js, s) Cu.reportError(r); I was able to spot this issue by running jetpack test on this branch: https://github.com/ochameau/addon-sdk/tree/cross-domain-content-script This branch is using new feature from bug 734891. You can run most important test like this: $ cd addon-sdk $ source bin/activate -or- bin\activate.bat $ cd packages/api-utils $ cfx test -v -f test-content-proxy -b /path/to/firefox

Ok so first of all why would you ever do something like this? In bug 734891 I added an optional xhr constructor to the sandbox (patch 5). Passing an XHR object like that and expecting that it can be used in a different compartment with a different principal is not the way to go. When you create an XHR object within the sandbox (you can do that if you set wantXHRConstructor option to true for the sandbox and simply call new XMLHttpRequest() inside the sandbox) it will have the expanded principal, and should just work.

Oh I forgot about that wantXHRContrustor argument. I can easily workaround this error with JS proxies, by catching all access to XMLHttpRequest property for all Window objects: https://github.com/ochameau/addon-sdk/commit/57917a87425869a218eb8fc95ed15c72c911ed8a#L0R692 But I think we may want to get this fixed for JS proxies removal, bug 738244. Various JS framework, like JQuery for ex, doesn't use XMLHttpRequest global, but window.XMLHttpRequest. We should be able to fix that with code similar to this: // Do not use xraywrapper as we can't delete native properties (yet?) let proto = content.wrappedJSObject; delete proto.XMLHttpRequest; let s = Cu.Sandbox([content.location.href, "http://bar.com"], { wantXHRConstructor: true, sandboxPrototype: proto }); Cu.evalInSandbox("window.XMLHttpRequest = XMLHttpRequest;", s); But then, if they use an iframe's XMLHttpRequest object, it will throw the same error.

(In reply to Alexandre Poirot (:ochameau) from comment #2) > But then, if they use an iframe's XMLHttpRequest object, it will throw the > same error. So I think that you should be able to use an XMLHttpRequest object if your principal subsumes the principal it was created with. So like in this case if your ExpandedPrincipal subsumes the principal of that iframe, it should be capable of using it. I will look into this why it does not work, I suspect another principal equal check somewhere instead of principal subsumes.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.