gNotificationBox doesn't go there anymore (it goes inside the toolbox),
so we have really no use for that.
Simplify how the devtools theme is set on the browser, so that it is set
on the root.
Differential Revision: https://phabricator.services.mozilla.com/D220769
Also prevent calling openSplitConsole when the console is already shown,
as it then breaks the internal state and would show the split console when switching to another panel.
Differential Revision: https://phabricator.services.mozilla.com/D213613
When there's a mutation and the client sees that the currently selected node
isn't connected anymore, a detached-front event is emitted with a node we think
is the parent node of the removed node, and select it.
Unfortunately, we were picking the first node who was mutated as the one we
should select, without checking that this mutation was the one triggered by the
node removal.
The fix is pretty simple: only pick a parent node if the currently selected node
is in the list of removed nodes from the mutation.
We're not adding a specific test for it, the next patch on the queue (for Bug 1173057),
has a test which was failing intermittently without this fix.
Differential Revision: https://phabricator.services.mozilla.com/D216667
Also moving the LOG_METHODS from actors to specs so that the frontend
can import them from devtools/shared instead of devtools/server.
Differential Revision: https://phabricator.services.mozilla.com/D215085
Also moving the LOG_METHODS from actors to specs so that the frontend
can import them from devtools/shared instead of devtools/server.
Differential Revision: https://phabricator.services.mozilla.com/D215085
The throttling prevents the removed iframe from emitting a THREAD_STATE resumed resource.
Instead, we should consider the related TARGET_DESTROYED event and resume on target destruction.
Differential Revision: https://phabricator.services.mozilla.com/D213929
The issue is that some calls to JSProcess Actor's would throw when trying to reach
content processes that get destroyed while DevTools are opening.
We have to reach out all the content processes as navigations may spawn
document in a process other than the currently's debugged tab's process.
We should ignore these failures. There isn't any explicit flag on DOM Process object
to identify destroyed processes, but `canSend` is a good fallback.
Differential Revision: https://phabricator.services.mozilla.com/D212118
The issue is that some calls to JSProcess Actor's would throw when trying to reach
content processes that get destroyed while DevTools are opening.
We have to reach out all the content processes as navigations may spawn
document in a process other than the currently's debugged tab's process.
We should ignore these failures. There isn't any explicit flag on DOM Process object
to identify destroyed processes, but `canSend` is a good fallback.
Differential Revision: https://phabricator.services.mozilla.com/D212118
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
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
Emilio Cobos Álvarez