Bugzilla

In order to convert backend modules of DevTools to ESM we would need a way to load these modules in a distinct system compartment.

For now we are using either `freshCompartment: true` or `invisibleToDebugger: true` arguments of `Sandbox` in order to load all CommonJS modules in a distinct system compartment.
This is only important in the case of the Browser Toolbox, i.e. when we debug the browser.
When we debug the browser itself, we have to:
* load DevTools modules independantly of the ones loaded for regular DevTools. We don't want to share any possible state.
* have a way to distinguish the two set of modules and ignore the one related to the brower toolbox. This is especially important for the debugger in order to avoid pausing in code related to the browser toolbox.

For now, the CommonJS modules are loaded via `loadSubScript` in hand-crafted JS `Sandbox()`.

We could possibly use a regumar `import` method from a hand-crafted document, using the right principal. Similaryl to attachment 9041865 [details].
But I suspect that any inner usage of `ChromeUtils.defineESModuleGetters` is going to fallback to load the ESM in the shared system global instead of the one from the caller...
(There is also possible usage of `ChromeUtils.import`, but we could say we have to convert them to regular `import x from;`)

I see two possible call for actions here:
* make `ChromeUtils.defineESModuleGetters` try to use the callsite's module loader, if called from a ESM. Does that sound feasible/reasonable?
* may be also expose an API to more esily load a ESM in this "distinct system compartment". So that it is simplier to load the very first devtools backend JSM.

But I'm open to suggestions and alternative plan here.
I think that WebExtension might need something alongside these lines. Any bug already opened?

In order to convert backend modules of DevTools to ESM we would need a way to load these modules in a distinct system compartment.

For now we are using either `freshCompartment: true` or `invisibleToDebugger: true` arguments of `Sandbox` in order to load all CommonJS modules in a distinct system compartment.
This is only important in the case of the Browser Toolbox, i.e. when we debug the browser.
When we debug the browser itself, we have to:
* load DevTools modules independantly of the ones loaded for regular DevTools. We don't want to share any possible state.
* have a way to distinguish the two set of modules and ignore the one related to the brower toolbox. This is especially important for the debugger in order to avoid pausing in code related to the browser toolbox.

For now, the CommonJS modules are loaded via `loadSubScript` in hand-crafted JS `Sandbox()`.

We could possibly use a regumar `import` method from a hand-crafted document, using the right principal. Similaryl to attachment 9041865 [details].
But I suspect that any inner usage of `ChromeUtils.defineESModuleGetters` is going to fallback to load the ESM in the shared system global instead of the one from the caller...
(There is also possible usage of `ChromeUtils.import`, but we could say we have to convert them to regular `import x from;`)

I see two possible call for actions here:
* make `ChromeUtils.defineESModuleGetters` try to use the callsite's module loader, if called from a ESM. Does that sound feasible/reasonable?
* may be also expose an API to easily load a ESM in this "distinct system compartment". So that it is simplier to load the very first devtools backend JSM.

But I'm open to suggestions and alternative plan here.
I think that WebExtension might need something alongside these lines. Any bug already opened?