This flag was only used by the allocation tracker test and we can now rely on the
DevTools global spawn by mozJSModuleLoader.
Differential Revision: https://phabricator.services.mozilla.com/D253049
The 'invisibleToDebugger' flag was misleading and making all Loaders be indebuggable on xcpshell.
But we have to keep spawning the xpcshell's DevToolsServer in the distinct "devtools" global
in order to be able to debug the tests and devtools globals now all spawn in the shared system global.
Differential Revision: https://phabricator.services.mozilla.com/D252530
Display requests in the netmonitor for data URIs.
Currently, some data-uris are leaking from internal stylesheets such as resource://gre-resources/html.css but this should hopefully be rare.
Another bug has been filed to properly filter out those requests.
A simple test is added to make sure we can see parent process and content process data uris.
Differential Revision: https://phabricator.services.mozilla.com/D217413
Display requests in the netmonitor for data URIs.
Currently, some data-uris are leaking from internal stylesheets such as resource://gre-resources/html.css but this should hopefully be rare.
Another bug has been filed to properly filter out those requests.
A simple test is added to make sure we can see parent process and content process data uris.
Differential Revision: https://phabricator.services.mozilla.com/D217413
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
The Worker Target URL is now correctly set to the Absolute URL,
this has an impact on the context selector as we are displaying it.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
The Worker Target URL is now correctly set to the Absolute URL,
this has an impact on the context selector as we are displaying it.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
Having it be a JSM make it so that part of the loader is still using the
shared loader global, which can cause various troubles in the browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D167962
The modification made to Loader isn't necessary as the sandboxName
isn't relevant/used. The global will be the one crafted by C++
and be named "Devtools global".
But in case something change, this may catch yet another unexpected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D166122
The modification made to Loader isn't necessary as the sandboxName
isn't relevant/used. The global will be the one crafted by C++
and be named "Devtools global".
But in case something change, this may catch yet another unexpected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D166122
Now that source-map-loader uses ChromeLoader, it doesn't need to be loaded
via the Browser Loader. It was mostly used to be able to access window.Worker symbol.
It was also exposing `fetch` global symbol. DevTools Loader wasn't exposing it.
I fixed that as this symbol is available in JSM/ESM.
Differential Revision: https://phabricator.services.mozilla.com/D162966
ESM can't be loaded while loading.
So that Loader.jsm/sys.mjs can't load builtin-modules.js with itself loading Loader.jsm/sys.mjs.
We do that in order to inject JSM/ESM globals from builtin-modules.js.
Let's instead inject the few globals of JSM/ESM directly from Loader.
This isn't ideal, but as Loader is meant to be removed when moving to ESM...
Differential Revision: https://phabricator.services.mozilla.com/D158583
Lorenz A