These are generally cases where the exclusion is no longer necessary, because we've fixed whatever was causing it to be added in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D300083
This reverts commit f572e49026.
Revert "Bug 1924775 - Use a defined version of the "globals" npm module, and resolved raised issues. r=frontend-codestyle-reviewers,devtools-reviewers,home-newtab-reviewers,flozia,nchevobbe,mossop,thecount"
This reverts commit e0f4d195f8.
These are generally cases where the exclusion is no longer necessary, because we've fixed whatever was causing it to be added in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D300083
This reverts commit 1a90fee5f3.
Revert "Bug 1924775 - Use a defined version of the "globals" npm module, and resolved raised issues. r=frontend-codestyle-reviewers,devtools-reviewers,home-newtab-reviewers,flozia,nchevobbe,mossop,thecount"
This reverts commit 9b2da35aba.
These are generally cases where the exclusion is no longer necessary, because we've fixed whatever was causing it to be added in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D300083
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
This will help bug 1569775 and bug 1651522 to update the whole entries of a given data type.
As there is little difference between adding new entries and replacing all entries,
I'm tuning the existing addSessionDataEntry methods to support both behaviors.
Differential Revision: https://phabricator.services.mozilla.com/D192243
test_stepping-12.js wasn't correctly waiting for thread to be resumed between each of its sub test.
Similarly, other tests weren't waiting for thread front's resume request to be resume.
I'm also spreading the usage of resumeAndWaitForPause to better ensure we resume and wait for next paused event
without any race condition. Listening to "paused" after calling "resume" is subject to race conditions.
Differential Revision: https://phabricator.services.mozilla.com/D136125
Mark Banner