We were using process script and process message managers to interact with content processes.
This patch migrates the whole logic to JS Process Actor.
Note that we may still use old API in process descriptor, but that's a different story.
This helps align frame, process and worker targets all around JS Actors,
making it easier to align all three target types to the same logic.
Also fix passing `isModeSwitching` for content process targets
so that console is correctly cleared when switching between modes.
With this and the ongoing Service Worker equivalent work, we should be able to factorize some code.
Differential Revision: https://phabricator.services.mozilla.com/D167965
This will help bug 1569775 and bug 1651522 to update the whole entries of a given data type.
As there is little difference between adding new entries and replacing all entries,
I'm tuning the existing addSessionDataEntry methods to support both behaviors.
Differential Revision: https://phabricator.services.mozilla.com/D192243
We pass `isModeSwitching` to `unwatchTargets` from the target command when the
pref is changed.
On the server, we then pass it to the various places which might call `notifyTargetDestroyed`,
so we can pass the flag in the `target-destroyed-form` event, which we can then
pass to TargetCommand#onDestroyed callbacks.`
Differential Revision: https://phabricator.services.mozilla.com/D152758
This helps better differentiates cases where we instantiate a target actor
with a watcher actor and possibly debug the whole browser and instantiate many targets.
Or when we instantiate only one target actor, like when we debug workers or xpcshell from about:debugging.
For now, in this case, there is no watcher actor involved and we manually instantiate the target from the descriptor.
Differential Revision: https://phabricator.services.mozilla.com/D146584
This probably had many side effects in the browser toolbox when debugging content processes.
But the main one was about not properly unregistering breakpoints when removing/disabling it.
This is only specific to content process targets, so this is only impacting the browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D138325
Before, targets were created on-demand, from the frontend, by calling ProcessDescriptor.getTarget
when the root actor informed the frontend of a creation of a content process via processListChanged event
and the notification of a new ProcessDescriptor.
This previous behavior was making so that the target actor was created very late and did not allow
recording for resources (console messages for ex), nor setting breakpoints very early during the process startup.
With this new implementation, the watcher actor allows knowing if the frontend cares about content process target or not.
We should only create these targets if the browser toolbox is opened, and typically not if we are only debugging a tab via a regular web toolbox.
We do that via WatcherActor.watchTarget and sharedData object.
content-process-script.js is loaded in all processes. Process script are loaded quite early during process startup.
Soonish after `sharedData` is passed to the content process.
So that it is hopefully executed before most privileged javascript runs.
Javascript code where we possibly want to debug/observe/set a breakpoint on.
This setup allows us to create the Content Process Target actor much earlier than the previous setup.
When created, the target actor immediately start listening for resources (console message and others) via its `addWatcherDataEntry` method.
In a near future, breakpoints will also be set via this method.
We should also followup to use something else than Process Script and sharedData
in order to create the target earlier, before any JS runs.
Differential Revision: https://phabricator.services.mozilla.com/D65529
Mark Banner