Alexandre Poirot
6c428aaabd
* 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
34 lines
1.5 KiB
JavaScript
34 lines
1.5 KiB
JavaScript
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
"use strict";
|
|
|
|
/*
|
|
We want this to only startup the DevToolsProcess JS Actor on process start
|
|
and not when we only register the JS Process Actor when watching the first target type.
|
|
The Watcher Actor will query each individual JS Process Actor and fine control
|
|
the ordering of requests. It is especially important to spawn the top level target first.
|
|
*/
|
|
const isContentProcessStartup = !Services.ww
|
|
.getWindowEnumerator()
|
|
.hasMoreElements();
|
|
if (isContentProcessStartup) {
|
|
/*
|
|
We can't spawn the JSProcessActor right away and have to spin the event loop.
|
|
Otherwise it isn't registered yet and isn't listening to observer service.
|
|
Could it be the reason why JSProcessActor aren't spawn via process actor option's child.observers notifications ??
|
|
*/
|
|
Services.tm.dispatchToMainThread(() => {
|
|
/*
|
|
This notification is registered in DevToolsServiceWorker JS process actor's options's `observers` attribute
|
|
and will force the JS Process actor to be instantiated in all processes.
|
|
*/
|
|
Services.obs.notifyObservers(null, "init-devtools-content-process-actor");
|
|
/*
|
|
Instead of using observer service, we could also manually call some method of the actor:
|
|
ChromeUtils.domProcessChild.getActor("DevToolsProcess").observe(null, "init-devtools-content-process-actor");
|
|
*/
|
|
});
|
|
}
|