This doesn't help know what particular resource DevTools is currently inspecting,
but at least it helps know if it debugs something:
* one or many BrowsingContext(s) for regular DevTools (you can use BrowsingContext.watchedByDevTools instead)
* the whole process for the Browser Console/Toolbox
Differential Revision: https://phabricator.services.mozilla.com/D173295
This doesn't help know what particular resource DevTools is currently inspecting,
but at least it helps know if it debugs something:
* one or many BrowsingContext(s) for regular DevTools (you can use BrowsingContext.watchedByDevTools instead)
* the whole process for the Browser Console/Toolbox
Differential Revision: https://phabricator.services.mozilla.com/D173295
This will help transition to ES Modules as we won't be able to expose a magic "chrome" ESM.
Also, most of these symbols are exposed as global already.
All but:
* `components` which is `Components`,
* `CC` which is `Components.Constructor`,
* `Cm` which is `Components.manager`.
$ sed -ie "/require(.chrome.)/d" $(git grep -l 'require("chrome")' devtools/)
+ manual edits for all three exceptions
Differential Revision: https://phabricator.services.mozilla.com/D156936
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.Services.)/d" $(git grep -l 'require("Services")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .Services./d" $(git grep -l 'loader.lazyRequireGetter(this, "Services"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js
+ manual eslint fixes
+ removal of devtools-services in the debugger, except for jest tests
Differential Revision: https://phabricator.services.mozilla.com/D156401
Do that except when keepAlive attribute is set to true for server
listening for many incoming client connections.
This is the case when starting server via --start-debugger-server
or when starting the server from the mobile browser.
Differential Revision: https://phabricator.services.mozilla.com/D147876
Do that except when keepAlive attribute is set to true for server
listening for many incoming client connections.
This is the case when starting server via --start-debugger-server
or when starting the server from the mobile browser.
Differential Revision: https://phabricator.services.mozilla.com/D147876
This helps simplify DevToolsFrameChild and avoid registering and not leaking a connectionchange listener.
This also help always nullify this.loader in DevToolsFrameChild.
For some reason, the first time didDestroy is called, there is still another connection registered in the server.
Differential Revision: https://phabricator.services.mozilla.com/D147683
This intermediate actor is no longer useful for a while.
(Since we dropped the LocalTabProxy. I think since we introduced the TabDescriptor?)
I updated actor-hierarchy.md significantly as it was quite outdated!
We would probably benefit having a section dedicated to the WatcherActor.
Differential Revision: https://phabricator.services.mozilla.com/D126373
Each time the related WindowGlobal is destroyed, the related target actor and connection will be destroyed.
But the destruction of the previous actor/connection happens *after* the creation of the new.
So that hasConnection() is always true on reload. On toolbox closing it should become false.
Regardless, we should always unregister the connectionchange.
The server may be destroyed by the very last actor/connection to be destroyed.
We might want to move this code directly into DevToolsServer, that may be clearer...
But that may break non-watcher setup, so better do that once we only support the watcher codepath.
Differential Revision: https://phabricator.services.mozilla.com/D126085
When running test_webconsole-node-grip.html with server side target switching,
the test was failing as accessing this._connections[connID] was returning a
null object.
From some quick investigation, it looks like the object was nullified after
a first connection was closed.
Retrieving all the connection objects before looping closing them seems to
fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D121165
Renaming the actor makes it more explicit that it should
only be used for highlighter-related assertions.
We take this opportunity to rename all the 'testActor' instances
in tests to 'highlighterTestFront' which better represents
what the object is.
While doing this work, I was able to cleanup a few function definition
where the testActor parameter wasn't needed.
Differential Revision: https://phabricator.services.mozilla.com/D117978
This patch adds support for dedicated worker targets in the Watcher actor.
Shared and Service workers are not handled yet.
In a similar manner to what we already have for frame targets, we add a worker-helper
file that will communicate with a JsWindowActor pair spawned on each document,
that will manage workers (DevToolsWorkerParent/DevToolsWorkerChild).
For a given document, the DevToolsWorkerChild will enumerate the existing workers
related to it, as well as add an event listener to be notified when workers are
being registered and unregistered, and communicate that back to the DevToolsWorkerParent
on the main thread, so worker targets creation and destruction are notified by
the Watcher actor (via target-available-form and target-destroyed-form events).
When a worker is created, the DevToolsWorkerChild for the document the worker
was spawned from will create a WorkerTargetActor, that will live in the worker
thread (using worker-connector.js), passing it resources the Watcher is currently
listening for. It will also handle communication between the main thread and the
worker thread, when the watcher listen to new resources (or stop watching resources).
A WorkerTargetFront is created so the client can be notified about available
resources (via the resource-available-form event, emitted from the worker target).
Tests are added in the next patches of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D85399
This patch adds support for dedicated worker targets in the Watcher actor.
Shared and Service workers are not handled yet.
In a similar manner to what we already have for frame targets, we add a worker-helper
file that will communicate with a JsWindowActor pair spawned on each document,
that will manage workers (DevToolsWorkerParent/DevToolsWorkerChild).
For a given document, the DevToolsWorkerChild will enumerate the existing workers
related to it, as well as add an event listener to be notified when workers are
being registered and unregistered, and communicate that back to the DevToolsWorkerParent
on the main thread, so worker targets creation and destruction are notified by
the Watcher actor (via target-available-form and target-destroyed-form events).
When a worker is created, the DevToolsWorkerChild for the document the worker
was spawned from will create a WorkerTargetActor, that will live in the worker
thread (using worker-connector.js), passing it resources the Watcher is currently
listening for. It will also handle communication between the main thread and the
worker thread, when the watcher listen to new resources (or stop watching resources).
A WorkerTargetFront is created so the client can be notified about available
resources (via the resource-available-form event, emitted from the worker target).
Tests are added in the next patches of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D85399
Alexandre Poirot