This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
`InspectorUtils.getRuleBodyTextOffset` was returning bytes position, and we
were using them directly in Javascript `substring`, which causes problem
with non-ascii chars.
Instead of returning offsets to compute the rule string, we directly return
the string from InspectorUtils which is easier to work with.
Differential Revision: https://phabricator.services.mozilla.com/D204523
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
We were only processing the first one being registered.
Luckily we weren't testing session data enough in xpcshell to have trouble because of this.
(this changeset fixes test failure when applying the next one)
Differential Revision: https://phabricator.services.mozilla.com/D203101
Since we're at the end of the cycle, let's fix the regression
by reverting getRuleText to use the JS lexer again.
A test case is added to prevent future regression when we'll
try to move this to an InspectorUtils method again.
Differential Revision: https://phabricator.services.mozilla.com/D204621
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
We were only processing the first one being registered.
Luckily we weren't testing session data enough in xpcshell to have trouble because of this.
(this changeset fixes test failure when applying the next one)
Differential Revision: https://phabricator.services.mozilla.com/D203101
By protocol.js conventions, most target scopes actors have a `targetActor` attribute set to their parent,
i.e. the related target actor. Thread Actor was old enough to not follow this pattern.
Also remove the second constructor argument and `global` attribute as it was unused.
Differential Revision: https://phabricator.services.mozilla.com/D201696
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
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
Conditional breakpoints weren't preventing breakpoints from being hit and could pause in many unexpected ways.
It requires some tweaks regarding disableBreaks argument as we still have to notify about pause on exception
to ensure notifying the user when the condition throws.
Introduce the `reportExceptionsWhenBreaksAreDisabled` flag for this.
Otherwise it looks like we were not having test actually asserting the the condition breakpoint
actually worked for real and paused page execution. We were only having test covering the UI state.
Differential Revision: https://phabricator.services.mozilla.com/D182456
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
The WebExtensionDescriptorActor loaded extension modules with the
dedicated devtools loader, which returns a different instance than
the real module in the browser. Besides the code not being designed to
be loaded twice in the same browser instance, this has the following
devtools-protocol-observable consequences:
- Uninitialized AddonManager -> Unable to detect addon updates/uninstalls.
- Detached ExtensionParent -> Unable to observe the actual extension,
including not seeing extension state such as warnings.
Differential Revision: https://phabricator.services.mozilla.com/D180292
This patch was generated as follows:
Run:
`./mach esmify --imports . --prefix=toolkit/mozapps/extensions/AddonManager`
In the output there are linter/prettifier errors due to unused
XPCOMUtils or separate importESModule calls. These have been fixed
manually and verified with `./mach lint --outgoing`.
The `esmify` script also inserts many unwanted newlines around imports
that are broken on two lines due to length. Due to the number of these,
I fixed them programatically.
1. Create patch from the changes so far.
2. From the patch, delete all lines that consist of "+" (i.e. added blank line).
3. Reset the working dir and apply the revised patch.
4. Verify that the diff between step 1 and 3 looks reasonable.
5. Verify that this patch as a whole looks reasonable.
Commands:
```
git diff > rename.diff
:%g/^+$/d
git commit -va -m WIP-rename
git revert HEAD
git apply --recount rename.diff
git diff HEAD^ # and verify that the removed lines are ok.
git commit -va # one last review to verify correctness of whole patch.
git rebase -i HEAD~3 # drop the WIP + reverted commit, pick only the last.
```
`git apply` has the `--recount` option to force it to ignore mismatches
in line counts, which happens because we deleted added lines (^+$)
without fixing up the line counts in the file headers.
Differential Revision: https://phabricator.services.mozilla.com/D179874
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
Alexandre Poirot