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
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
We used to force the preferences for the new performance panel to true for the Browser Toolbox to avoid showing the old performance panel, regardless of the preferences set by the user for their regular devtools.
However, now that the old performance panel is gone, it should be fine to let users decide if they want the panel or not via the devtools Settings panel.
Also the performance panel is on by default, so it shouldn't make it more complicated to profile on clean profiles.
Differential Revision: https://phabricator.services.mozilla.com/D210148
* 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
* 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
Register them as soon as we open devtools, instead of waiting for debugger panel opening.
So that breakpoints can work even if we did not open debugger panel yet.
So far, only debugger statement would force the opening of the debugger.
This allows to remove the redundant code from debugger frontend.
Also clarify in this patch that thread-utils exports thread configurations.
Differential Revision: https://phabricator.services.mozilla.com/D205772
This should help connect preferences to server's target configurations.
Once we get rid of thread's actor attach sequence, we may be able to also fold the getThreadOptions's preferences into this new system.
Differential Revision: https://phabricator.services.mozilla.com/D202277
`devtools.debugger.features.overlay` boolean preference will control this paused overlay.
(same name as an old preference which used to do that)
Differential Revision: https://phabricator.services.mozilla.com/D201697
It allows
* toggling Source Map support entirely
* open the source map URL (when a bundle file is currently selected)
* open the mapped source (original or bundle)
* toggle the "open original source by default" setting
* show source map status (source map error, is it original or bundle file, is this a regular source?)
Differential Revision: https://phabricator.services.mozilla.com/D187577
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
It allows
* toggling Source Map support entirely
* open the source map URL (when a bundle file is currently selected)
* open the mapped source (original or bundle)
* toggle the "open original source by default" setting
* show source map status (source map error, is it original or bundle file, is this a regular source?)
Differential Revision: https://phabricator.services.mozilla.com/D187577
Ensure updating the tracing state from the TracerCommand,
so that its internal state is correct whenever we start tracing
via the console or debugger.
Differential Revision: https://phabricator.services.mozilla.com/D196961
The main goal here is to re-throw the exception so that the debugger can start displaying source map errors.
Note that the previous changeset tweaked the StyleEditor code to handle exceptions.
The Debugger will be handled in the next changeset.
Differential Revision: https://phabricator.services.mozilla.com/D187576
The main goal here is to re-throw the exception so that the debugger can start displaying source map errors.
Note that the previous changeset tweaked the StyleEditor code to handle exceptions.
The Debugger will be handled in the next changeset.
Differential Revision: https://phabricator.services.mozilla.com/D187576
Some workers running in the parent process might be initializating or destroying
and their target front won't be fully populated.
This test is brittle as it interact with any firefox parent process worker.
As we don't control them from the test they may be in arbitrary state.
Differential Revision: https://phabricator.services.mozilla.com/D197092
This help reduce the RDP overhead by only transferring what is strictly necessary.
The console message resources bundles various useless attributes.
This also help use a custom rendering in the frontend so that traces can
be displayed distinctly and differently from the console API calls.
Differential Revision: https://phabricator.services.mozilla.com/D196020
This help reduce the RDP overhead by only transferring what is strictly necessary.
The console message resources bundles various useless attributes.
This also help use a custom rendering in the frontend so that traces can
be displayed distinctly and differently from the console API calls.
Differential Revision: https://phabricator.services.mozilla.com/D196020
For some reason, the debugger has a different behavior the second time it opens
compared to its very first opening. So that distinct React elements are instantiated
and are then reported as leaks...
Differential Revision: https://phabricator.services.mozilla.com/D196191
DOM mutation breakpoints are set on specific node fronts,
and we would keep retrieving node fronts from now discarded
targets after the page navigated.
Differential Revision: https://phabricator.services.mozilla.com/D193087
We had to skip-if those tests that were crashing during a11y_checks and since the bug 1849230 is resolved now these test can be re-enabled (whenever possible). Two tests have also been failing intermittently, thus they are remaining skipped, but the comment is updated to remove the mention of the crash.
Differential Revision: https://phabricator.services.mozilla.com/D193230
Cristian Tuns