This patch applies all the changes needed to the devtools actors
and the toolbox-process-window, to be able to debug a webextension
running in an extension child process (as well as a webextension
running in the main process).
The devtools actor used to debug a webextension is splitted into
3 actors:
- the WebExtensionActor is the actor that is created when the
"root.listTabs" RDP request is received, it provides the addon
metadata (name, icon and addon id) and two RDP methods:
- reload: used to reload the addon (e.g. from the "about:debugging#addons" page)
- connectAddonDebuggingActor: which provides the actorID of the actor
that is connected to the process where the extension is running
(used by toolbox-process-window.js to connect the toolbox to the needed
devtools actors, e.g. console, inspector etc.)
- the WebExtensionParentActor is the actor that connects to the
process where the extension is running and ensures that a
WebExtensionChildActor instance is created and connected
(this actor is only the entrypoint to reach the WebExtensionChildActor,
and so it does not provide any RDP request on its own, it only connect
itself to its child counterpart and then it returns the RDP "form" of
the child actor, and the client is then connected directly to the
child actor)
- the WebExtensionChildActor is the actor that is running in the same
process of the target extension, and it provides the same requestTypes
of a tab actor.
By splitting the WebExtensionActor from the WebExtensionParentActor, we are
able to prevent the RemoteDebuggingServer to connect (and create
instances of the WebExtensionChildActor) for every addon listed by
a root.listAddons() request.
MozReview-Commit-ID: L1vxhA6xQkD
--HG--
extra : rebase_source : 7ed7735084d9351ff32ab1ad822e53dd0828dace
This patch applies all the changes needed to the devtools actors
and the toolbox-process-window, to be able to debug a webextension
running in an extension child process (as well as a webextension
running in the main process).
The devtools actor used to debug a webextension is splitted into
3 actors:
- the WebExtensionActor is the actor that is created when the
"root.listTabs" RDP request is received, it provides the addon
metadata (name, icon and addon id) and two RDP methods:
- reload: used to reload the addon (e.g. from the "about:debugging#addons" page)
- connectAddonDebuggingActor: which provides the actorID of the actor
that is connected to the process where the extension is running
(used by toolbox-process-window.js to connect the toolbox to the needed
devtools actors, e.g. console, inspector etc.)
- the WebExtensionParentActor is the actor that connects to the
process where the extension is running and ensures that a
WebExtensionChildActor instance is created and connected
(this actor is only the entrypoint to reach the WebExtensionChildActor,
and so it does not provide any RDP request on its own, it only connect
itself to its child counterpart and then it returns the RDP "form" of
the child actor, and the client is then connected directly to the
child actor)
- the WebExtensionChildActor is the actor that is running in the same
process of the target extension, and it provides the same requestTypes
of a tab actor.
By splitting the WebExtensionActor from the WebExtensionParentActor, we are
able to prevent the RemoteDebuggingServer to connect (and create
instances of the WebExtensionChildActor) for every addon listed by
a root.listAddons() request.
MozReview-Commit-ID: L1vxhA6xQkD
--HG--
extra : rebase_source : f9438b4a9842c1dd504edf2fcd87857c670f411f
MozReview-Commit-ID: J1EmwxplNhA
Make actor registration more explicit and documented.
Each codepath depends on various set of actors, and it may be confused
as we often register actors if the DebuggerServer wasn't initialized yet.
But it is often already started by some other callsite...
This changeset also converts childtab to being just a module
and stop using DebuggerServer.addActors magic.
--HG--
extra : rebase_source : acbfd98b7791c833181d655d6cae04ec9bb28f87
Ever since protocol.js was added as a way to create DevTools actors, we've had
lots of confusion about the correct way to implement actor destruction. If your
actor's _parent_ was the legacy kind, you had to use `disconnect`. If it was
protocol.js, you had to use `destroy`.
There is no reason for this madness, which makes reasoning about destruction
quite hard. Here we rename `disconnect` to `destroy` so there is only one name
for every destruction path.
MozReview-Commit-ID: C1Yw9NfUUR2
--HG--
extra : rebase_source : 4d018622b7547d404510e0b563c6324c0127aafc
Watch for browser swap events and update the message manager as necessary for
each of the actors that use the `setupInParent` multiprocess functionality.
MozReview-Commit-ID: HPibSONSYk4
It is now possible keep the toolbox open while toggling RDM open and closed.
The toolbox will follow the frame as it moves and update the message manager it
uses internally with each move.
MozReview-Commit-ID: DvLzCmOXfnb
The removes the legacy path for non-e10s that avoids the messageManager. We now
use the messageManager for all cases, both e10s off and on.
Unsurprisingly, this revealed a variety of race conditions in various tests, so
they've been cleaned up as well.
MozReview-Commit-ID: EXEWehphLIY
For simple rules like function spacing, we can auto-fix these across the code
base so they are followed in a consistent way.
To generate this patch, I ran:
./mach eslint devtools --no-ignore --fix
After this, I reverted any changes to third party files that we really do want
to ignore.
MozReview-Commit-ID: 6Q8BApkAW20
This commit creates the HeapSnapshotFileActor and moves the transferHeapSnapshot
method from MemoryActor to HeapSnapshotFileActor. This is necessary because
child processes in e10s are sandboxed and do not have access to the file system,
and because MemoryActor is in the sandboxed child process it cannot open the
file and send it over the RDP.
This complexity is hidden at the MemoryFront layer. Users of MemoryFront will
still simply call its saveHeapSnapshot method, and do not need to worry about
the inner workings of how heap snapshot files are transferred over the RDP. This
required adding a third parameter to MemoryFront's initialize method: the
listTabs response.
This commit creates the HeapSnapshotFileActor and moves the transferHeapSnapshot
method from MemoryActor to HeapSnapshotFileActor. This is necessary because
child processes in e10s are sandboxed and do not have access to the file system,
and because MemoryActor is in the sandboxed child process it cannot open the
file and send it over the RDP.
This complexity is hidden at the MemoryFront layer. Users of MemoryFront will
still simply call its saveHeapSnapshot method, and do not need to worry about
the inner workings of how heap snapshot files are transferred over the RDP. This
required adding a third parameter to MemoryFront's initialize method: the
listTabs response.
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
