We were only increasing the index by 1, which wouldn't account for surrogate pairs (e.g. emojis).
We need to increase the index by the character length so the string can be manipulated accurately
after.
Test case is added to cover the fix.
Differential Revision: https://phabricator.services.mozilla.com/D275419
Lets start triggering updates at certain keypoint in the cycle instead
batching into one update at the end.
This should depend on mechanisim for throttling resources so as not to spam the
frontend with lots of updates
Differential Revision: https://phabricator.services.mozilla.com/D247424
This consolidates the jest environment definition, and the xpcshell globals into the devtools/.eslintrc.mjs file, for easier configurations.
It also changes the restart of the configurations to work with flat config.
Differential Revision: https://phabricator.services.mozilla.com/D249948
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
Chris H-C