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
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
Modifying the content of the list of resources may suddently start or stop receiving new resources types,
that, without calling (un)watchResources again!
Differential Revision: https://phabricator.services.mozilla.com/D205603
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 is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
Modifying the content of the list of resources may suddently start or stop receiving new resources types,
that, without calling (un)watchResources again!
Differential Revision: https://phabricator.services.mozilla.com/D205603
It is always tricky to test the Browser Toolbox codepaths as you may have various targets
related to previous test/tasks which are being destroyed in middle of the test.
Here some target related to previous task were removed in middle of this assertion.
It is better to test for actual deterministic content we are expecting rather than counting targets.
Differential Revision: https://phabricator.services.mozilla.com/D210668
Error were thrown when trying to fetch headers and cookies, which was preventing inspecting them fully.
Fixing that, enable seeing about:neterror requests which were trigerring a file:// URI request (at least on local builds).
So that we now have to explicitly ignore these error requests.
Differential Revision: https://phabricator.services.mozilla.com/D210319
In some cases, it can be more useful to only get the token value than the whole
token text (e.g. for 'Function`, where the value is the function name, while
the text includes the opening parenthesis)
Refactor `test_lexer` to better test the tokens we get, including their value property.
Differential Revision: https://phabricator.services.mozilla.com/D207400
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
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
Git isn't able to detect the file being only renamed in the previous changeset
as the changes made to it are too important.
So, use a distinct changeset to apply the file rename.
Differential Revision: https://phabricator.services.mozilla.com/D205988
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
Cristian Tuns