We should probably expose new RDP methods to prevent relying on console evaluations for this.
We would still have some potential issues if the evaluated method is about a JS symbol
whose name is the console command.
Differential Revision: https://phabricator.services.mozilla.com/D200167
Let's avoid tracing content process targets for now as this would require some more work (bug 1874204).
Also ignore web extension documents as they are all running in the same process dedicated to WebExt.
(JavaScriptTracer class only support being instantiated once per thread and all these documents run on the same)
(bug 1874219)
Differential Revision: https://phabricator.services.mozilla.com/D200169
Because the JavaScript tracer is currently running in each process/thread/target actor independently,
it is more complex to make it record across navigations as it may be spawn in a distinct process.
While it is fine for stdout and webconsole outputs (we could just spawn many concurrent tracers in each process),
this is more complex for the experimental "profiler" output.
For now, the profiler output automatically stops on target destruction and will open the profiler result.
By having an option to start recording on next page load, it prevents starting the tracer and prevent logging traces
for the current WindowGlobal. It should help focus on the new document.
For the profiler output, it prevents having the profiler to show up for the previous WindowGlobal.
Sideby tweak:
* stop passing logMethod and consider, like other option to be coming from the preferences.
* fix confusing state when debugging a page running in the same process.
Differential Revision: https://phabricator.services.mozilla.com/D196874
This simplifies toggling the Tracer on all active targets.
But this will be especially useful in the next changeset.
This allows to have two distinct level of enabling:
* the target configuration
* the actual start of tracing done by the tracer (on user interaction or next page load)
Doing this allows to distinguish tracer simple enabling,
when "trace on next user interaction" is enabled,
where we can display a badge on the tracer icon to significate it isn't tracing just yet.
And actual start of the tracer, when the first user interaction happens,
where we can remove the badge.
Differential Revision: https://phabricator.services.mozilla.com/D198961
Since we were waiting for the watch promise to resolve before adding the watcher
to the watchers Map, we had cases where the destroy/unwatch code was called while
we were waiting, causing some listeners to not be properly unregistered.
Differential Revision: https://phabricator.services.mozilla.com/D199959
With this it's easier to handle existing stylesheets (or to ignore them).
As the stylesheets resource now calls `watch`, we can remove StyleSheetsManager
events that were only used there.
Differential Revision: https://phabricator.services.mozilla.com/D199612
Don't register StyleSheetApplicableStateChanged/StyleSheetRemoved/window-ready events
if they were already registered before.
We take this as an opportunity to control those event listeners
with an AbortController to make it cleaner in destroy.
Differential Revision: https://phabricator.services.mozilla.com/D199611
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
This revealed that some of the pseudo methods were used outside of the StyleSheetsManager,
so we're making them public instead.
Differential Revision: https://phabricator.services.mozilla.com/D199610
These two settings are only available via the web console commands as they expect number as arguments
which is hard to implement via the context menu on the debugger button.
Move stdout logging to a dedicated method as onEnterFrame reached eslint complexity limit.
Differential Revision: https://phabricator.services.mozilla.com/D196832
The JavaScript Tracer may be initiated by the debugger, or stoped by itself when reaching some limit.
In these cases, the start and stop messages wouldn't have been logged in the console.
Differential Revision: https://phabricator.services.mozilla.com/D196831
These two settings are only available via the web console commands as they expect number as arguments
which is hard to implement via the context menu on the debugger button.
Move stdout logging to a dedicated method as onEnterFrame reached eslint complexity limit.
Differential Revision: https://phabricator.services.mozilla.com/D196832
The JavaScript Tracer may be initiated by the debugger, or stoped by itself when reaching some limit.
In these cases, the start and stop messages wouldn't have been logged in the console.
Differential Revision: https://phabricator.services.mozilla.com/D196831
The scrollend event has been content enabled by default for about a
year. Remove the preference that allows the feature to be chrome-only.
Differential Revision: https://phabricator.services.mozilla.com/D197699
Updating eslint-plugin-react to 7.33.2 raises new eslint errors.
A few component needed to have their proptypes fixed (or added).
JSPropertyProvider was considered as a react component by the plugin,
I guess because it is a function starting with an uppercase letter.
Since it is a bit unusual to have such thing, I renamed it slightly
to make it look more like a function.
Differential Revision: https://phabricator.services.mozilla.com/D197596
This requires to manually toggle "dom.worker.console.dispatch_events_to_main_thread" to false
in order to spawn targets for workers.
I had to disable throttling for workers because of missing setTimeout/clearTimeout methods
in worker modules. Hopefully we could get access to these methods when migrating to ESM?
Differential Revision: https://phabricator.services.mozilla.com/D196852
Introduce a new global option in the tracer to log values.
For now, it only triggers javascript function call arguments to be logged,
but this will also impact the incoming feature logging native function calls,
and also the other incoming feature to log the returned values.
Differential Revision: https://phabricator.services.mozilla.com/D196019
This help reduce the RDP overhead by only transferring what is strictly necessary.
The console message resources bundles various useless attributes.
This also help use a custom rendering in the frontend so that traces can
be displayed distinctly and differently from the console API calls.
Differential Revision: https://phabricator.services.mozilla.com/D196020