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
This new InspectorCSSParser makes use of the cssparser crate so DevTools end
up using the same code as the CSS engine.
At the moment, we can't get the token start and end offsets, so we create
a JS wrapper class to compute them in JS. This might be removed if we get
a way to retrieve utf16 position from the cssparser.
The existing lexer xpcshell test is modified so it can run against both js-based
and rust-based lexers.
Differential Revision: https://phabricator.services.mozilla.com/D202909
global option supercedes loadInDevToolsLoader, with omitting the
implicit contextual loader behavior.
In order to make the API less error-prone, use global option, with requireing
global option in DevTools global, to choose from shared global or explicit
contextual loader.
Differential Revision: https://phabricator.services.mozilla.com/D199466
The implementation of base-loader operates on stringly-typed URIs with path
methods. Refactoring this module to use paths and URIs is beyond the scope of
removing OS.File, so the methods from ospath_unix.jsm have been copied into the
module.
Differential Revision: https://phabricator.services.mozilla.com/D170107
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
This complexify the existing tests a bit, but will make the management from the Toolbox more obvious.
The metrics test highlights that we allow to prevent loading the sourcemap modules
unless it is strictly necessary!
(Also I forgot to remove the source-map-loader from the list of browser loader module...)
Differential Revision: https://phabricator.services.mozilla.com/D164694
This complexify the existing tests a bit, but will make the management from the Toolbox more obvious.
The metrics test highlights that we allow to prevent loading the sourcemap modules
unless it is strictly necessary!
(Also I forgot to remove the source-map-loader from the list of browser loader module...)
Differential Revision: https://phabricator.services.mozilla.com/D164694
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
This used to be a node package. Let's make it become regular commonjs devtools modules.
This will make it trivial to migrate this to ES Modules.
Also possibly make this code become the unique layer in m-c on top of the source-map package.
We no longer use webpack to build the two bundles (index.js and worker.js),
instead, we are using the toolkit worker loader (require.js) in order to load
all this code without any build step.
As this is no longer a node package, I removed node-specific modules (assertRoot/wasmAsset)
and simplify the definition of wasm file URIs as they are now fixed.
Also moving the debugger to load internal "devtools/client/shared/source-map/source-map.js"
module in jest as running the Web Worker instantiated by source-map/index.js is too complex.
Differential Revision: https://phabricator.services.mozilla.com/D159115
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
Gregory Pappas