This code was only used for workers targets, which weren't passing breakpoints
from the server side via "sessionData" concept.
Instead, we were still relying on the frontend to pass them and only after that
manually requesting the thread to resume its execution.
Now, there is still a notion of "attach" around the thread actor.
While all the targets are immediately instantiating their related thread actor,
the thread actor isn't active by default.
It becomes active as soon as:
* SOURCE or THREAD_STATE resource is watched
* breakpoints are set via session data (breakpoint list actor)
* thread configuration are set via session data (thread configuration actor)
I had to do one of these things in order to keep test from working.
In the production code, we do most of these things by default on the toolbox startup.
We could revise this behavior by:
* always attaching the thread actor, but it may start pausing unexpectedly in some tests.
* decouple sources from breakpoints within the thread actor, so that watching for sources doesn't necessarily "attach" the thread actor and activate breakpoints/debugger statements.
* have a new thread configuration to explicitly enable the thread actor pausing features.
I'm often using thread configuration to enable pausing in tests.
This required to improve xpcshell test helpers to be able to use Watcher/Commands.
About browser_target_command_bfcache.js, the DevTools code is now so quick that the
back/forward requests at done too quickly one after the other and fail actually moving to
the other document.
Differential Revision: https://phabricator.services.mozilla.com/D166321
This code was only used for workers targets, which weren't passing breakpoints
from the server side via "sessionData" concept.
Instead, we were still relying on the frontend to pass them and only after that
manually requesting the thread to resume its execution.
Now, there is still a notion of "attach" around the thread actor.
While all the targets are immediately instantiating their related thread actor,
the thread actor isn't active by default.
It becomes active as soon as:
* SOURCE or THREAD_STATE resource is watched
* breakpoints are set via session data (breakpoint list actor)
* thread configuration are set via session data (thread configuration actor)
I had to do one of these things in order to keep test from working.
In the production code, we do most of these things by default on the toolbox startup.
We could revise this behavior by:
* always attaching the thread actor, but it may start pausing unexpectedly in some tests.
* decouple sources from breakpoints within the thread actor, so that watching for sources doesn't necessarily "attach" the thread actor and activate breakpoints/debugger statements.
* have a new thread configuration to explicitly enable the thread actor pausing features.
I'm often using thread configuration to enable pausing in tests.
This required to improve xpcshell test helpers to be able to use Watcher/Commands.
About browser_target_command_bfcache.js, the DevTools code is now so quick that the
back/forward requests at done too quickly one after the other and fail actually moving to
the other document.
Differential Revision: https://phabricator.services.mozilla.com/D166321
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
For now, only console command values like $0, $_ and $x were allowed in eager evaluation,
only by luck as these commands were evaluated and cached *before* Frame.evalWithBinding and Object.executeInGlobalWithBindings
started running the console input string.
But methods were cancelled by onNativeCall. This new isSideEffectFree flag allows to identify these methods.
Differential Revision: https://phabricator.services.mozilla.com/D195022
We can start printing usage description right into the console by using `:command --help` or `:command --usage`.
I also simplified the integration between eval-with-debugger and manager
in order to fully delegate command execution to the manager.
Also improved the jsdoc for the register method. This new feature will be covered by test in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D193272
SharedArrayBuffer can only easily be testing through dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled
preference which is locked on beta and release channels.
Differential Revision: https://phabricator.services.mozilla.com/D192942
This is no longer used. The returned promise should be used instead.
There was also some old lefovers in WebConsole Front related to network events.
As we no longer have legacy listeners, this is no longer used.
The frontend code now uses DevToolsClient.request directly to query the NetworkEventActor's.
Differential Revision: https://phabricator.services.mozilla.com/D180980
This is no longer used. The returned promise should be used instead.
There was also some old lefovers in WebConsole Front related to network events.
As we no longer have legacy listeners, this is no longer used.
The frontend code now uses DevToolsClient.request directly to query the NetworkEventActor's.
Differential Revision: https://phabricator.services.mozilla.com/D180980
In the JSPropertyProvider, we are walking up the prototype to retrieve properties.
For proxies with `getPrototypeOf` trap, this means that we were returning erroneous
values, as the prototype chain of the proxy isn't altered by the trap.
Worse, it could lead to infinite loop if the trap was setting a circular reference.
To avoid this, when dealing with a proxy, we retrieve the prototype of the proxy
target.
Test cases are added to ensure we don't regress this.
Differential Revision: https://phabricator.services.mozilla.com/D179640
In the JSPropertyProvider, we are walking up the prototype to retrieve properties.
For proxies with `getPrototypeOf` trap, this means that we were returning erroneous
values, as the prototype chain of the proxy isn't altered by the trap.
Worse, it could lead to infinite loop if the trap was setting a circular reference.
To avoid this, when dealing with a proxy, we retrieve the prototype of the proxy
target.
Test cases are added to ensure we don't regress this.
Differential Revision: https://phabricator.services.mozilla.com/D179640
Stop supporting instance methods and getters in allowlist.
Now the allowlist is independent of global and can be shared across multiple
globals.
Differential Revision: https://phabricator.services.mozilla.com/D178884
Stop supporting instance methods and getters in allowlist.
Now the allowlist is independent of global and can be shared across multiple
globals.
Differential Revision: https://phabricator.services.mozilla.com/D178884
Now that all DOM getters are caught by `isNativeGetterWithJitInfo`,
we don't need the DOM getters in explicit allowlist.
Differential Revision: https://phabricator.services.mozilla.com/D175091
We used to support commands being registered by Add-ons or third party code.
We no longer do and can simplify this class.
This helped see a private field usage from eval-with-debugger.
Also remove hasCommand and getCommand which aren't used.
These methods were used in the past to wrap/chain commands,
which isn't done anymore.
Differential Revision: https://phabricator.services.mozilla.com/D177139
This code has been left unchanged since Firebug...
This ought some maintenance to better highlight where to implement new commands.
"utils.js" wasn't great ;)
Doing this highlights the fact that we have two type of commands.
See the new jsdoc alonside validCommands.
Differential Revision: https://phabricator.services.mozilla.com/D177138
Getters with LegacyLenientThis attribute will trigger a warning in the console
if it's called with the unexpected `this`.
We can't tell in DevTools if we have the "right" `this`.
For example displaying an `HTMLDivElementPrototype` object, we'll trigger the
warning because of the `onmouseenter` getter, which is supposed to be called
with the `HTMLElement` instance, which we don't have at this point.
For this reason, we exclude those from being safe getters, which will prevent
triggering the warning.
Differential Revision: https://phabricator.services.mozilla.com/D174070
Add support for [Global] extended attribute and methods/getters on instances.
This retrieves the Xray getter function of the given eval global, so that even
if some configurable properties are modified by the web content, debugger
can see the original getters, and pass them to isSameNativeWithJitInfo.
Differential Revision: https://phabricator.services.mozilla.com/D168339
Also refactor the allowlist structure to represent static vs prototype and
methods vs getters clearly.
And also moved the pre-defined pure methods list into GenerateDataFromWebIdls.py
for simplicity.
Differential Revision: https://phabricator.services.mozilla.com/D168338
Add support for [Global] extended attribute and methods/getters on instances.
This retrieves the Xray getter function of the given eval global, so that even
if some configurable properties are modified by the web content, debugger
can see the original getters, and pass them to isSameNativeWithJitInfo.
Differential Revision: https://phabricator.services.mozilla.com/D168339
Also refactor the allowlist structure to represent static vs prototype and
methods vs getters clearly.
And also moved the pre-defined pure methods list into GenerateDataFromWebIdls.py
for simplicity.
Differential Revision: https://phabricator.services.mozilla.com/D168338
Alexandre Poirot