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
This aligns all features in DevTools frontend currently evaluating some JavaScript code:
console input, eager evaluation, watch expression, log breakpoint, conditional breakpoint, inline preview, preview tooltips,
console "store as global", inspector "store as temp variable", DOM panel "window" retrieval,...
Except the console evaluation input, none of the many features evaluating code should:
* trigger any type of breakpoint via the evaluated code,
* evaluated sources should not be shown in the debugger.
This has been done by adding a `disableBreaks` argument to the web console actor evaluation method.
This mimic CDP's existing argument and disable trigerring any type of breakpoint,
while also avoiding instantiating Debugger.Source for the evaluated source.
Differential Revision: https://phabricator.services.mozilla.com/D180094
Tests that were using `evaluateJSAsync` are updated, either by using the new command,
or by awaiting for the `evaluationResult` event.
A couple chrome tests were moved to devtools/shared/commands/js/tests/ and turned
into browser tests, and some of them were completely removed as we tested the
features in mochitests as well.
Differential Revision: https://phabricator.services.mozilla.com/D116248
This method is meant to replace the direct usage
of webconsoleFront.evaluateJSAsync.
The WebConsoleCommands file is removed, and all
client calls to evaluateJSAsync are migrated to
the new method. Callsites are simplified when
possible, and some test are refactored to switch
to spawned task to retrieve content page information.
Differential Revision: https://phabricator.services.mozilla.com/D116242
Alexandre Poirot