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
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
This patch is only moving all network observer files in the same folder.
For webdriver reviewers, we could update our phabricator herald rule to be added as reviewers for changes in this folder?
Differential Revision: https://phabricator.services.mozilla.com/D160241
This is a very basic migration from commonjs modules to ESM for all modules related to network observation.
A few classes have been introduced instead of prototype-based classes, but otherwise the code remains mostly untouched.
We can followup to introduce private fields and methods if there's interest?
Differential Revision: https://phabricator.services.mozilla.com/D156968
Use 'globalThis' instead of 'this' when trying to attach a debugger to the
current global to avoid subtle footguns with the varied definitions of 'this'.
The debugger interface needs a true GlobalObject so this is much clearer. In
particular, this is a problem in test_nativewrappers.js when the test runs in
strict mode since the 'this' in the test function is no long implicitly the
global.
Differential Revision: https://phabricator.services.mozilla.com/D157544
This help factorise all code trying to instantiate a server and a client everywhere.
This will also help migrate from descriptor to commands in Toolbox constructor.
A good way to track all leftover manual instantiation of descriptors is to look for mainRoot.get*.
There should only be tests now, and descriptor-from-url, which I would to convert once
we migrate toolbox constructor from descriptor to commands.
Differential Revision: https://phabricator.services.mozilla.com/D157737
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.Services.)/d" $(git grep -l 'require("Services")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .Services./d" $(git grep -l 'loader.lazyRequireGetter(this, "Services"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js
+ manual eslint fixes
+ removal of devtools-services in the debugger, except for jest tests
Differential Revision: https://phabricator.services.mozilla.com/D156401
We can get a higher precision timestamp from microSecondTimeStamp, which will be consumed
in the console client to re-order messages.
This fixes an issue where different type of resources (console-messages and error-messages)
emitted during the same timestamp would not appear in the order they should be in.
A test is added to make sure the fix is effective.
Differential Revision: https://phabricator.services.mozilla.com/D155546
We can immediately "attach" the descriptor as it gets instantiated.
So that the frontend no longer need to call this before doing anything around the worker.
I also renamed the descriptor front method "attach" method,
in order to better highlight how special it is.
Hopefully we can drop this once the worker targets are created by the server.
i.e. when we enable service side worker targets for the browser toolbox,
which includes supporting service workers.
Differential Revision: https://phabricator.services.mozilla.com/D146787
Alexandre Poirot