Bug 1442347 - Get more globals from sandbox instead of JSM in DevTools. r=jdescottes
Pulling global properties from a JSM is a bit strange, so we should avoid it
where possible. This patch moves the properties available via
`wantGlobalProperties` over to that approach instead.
In the case of `XMLHttpRequest`, it is not actually expected to be available for
JSMs. If it were, it would be marked "Exposed=System". However, various
browser JSMs use `importGlobalProperties` to access it. These days, JSMs are
loaded into a shared global, so once one of these modules has called
`importGlobalProperties`, it becomes accessible via any JSMs loaded into that
shared global.
By moving XHR to the `wantGlobalProperties` style, we avoid this fun race.
MozReview-Commit-ID: 1umu94Qvlz9
--- a/devtools/shared/builtin-modules.js
+++ b/devtools/shared/builtin-modules.js
@@ -14,43 +14,49 @@
*/
const { Cu, CC, Cc, Ci } = require("chrome");
const promise = require("resource://gre/modules/Promise.jsm").Promise;
const jsmScope = require("resource://gre/modules/Services.jsm");
const { Services } = jsmScope;
// Steal various globals only available in JSM scope (and not Sandbox one)
const {
- atob,
- btoa,
- ChromeUtils,
console,
HeapSnapshot,
- TextDecoder,
- TextEncoder,
- XMLHttpRequest,
} = Cu.getGlobalForObject(jsmScope);
// Create a single Sandbox to access global properties needed in this module.
// Sandbox are memory expensive, so we should create as little as possible.
const {
+ atob,
+ btoa,
+ ChromeUtils,
CSS,
CSSRule,
FileReader,
indexedDB,
InspectorUtils,
+ TextDecoder,
+ TextEncoder,
URL,
+ XMLHttpRequest,
} = Cu.Sandbox(CC("@mozilla.org/systemprincipal;1", "nsIPrincipal")(), {
wantGlobalProperties: [
+ "atob",
+ "btoa",
+ "ChromeUtils",
"CSS",
"CSSRule",
"FileReader",
"indexedDB",
+ "TextDecoder",
+ "TextEncoder",
"InspectorUtils",
"URL",
+ "XMLHttpRequest",
]
});
/**
* Defines a getter on a specified object that will be created upon first use.
*
* @param object
* The object to define the lazy getter on.