When opening the debugger, we do watch worker targets in case we need to honor
some breakpoints.
If you started the console at some point, this will start watching console messages
resources, within the worker thread.
The issue is that if the `dom.worker.console.dispatch_events_to_main_thread` has
its default value, the worker messages are cloned from the worker thread to the
main thread, so when we start the debugger, we get duplicated messages: the cloned
ones, and the ones directly from the worker.
To fix this, we forward the value of the pref to the worker target so we can
bail out when it tries to watch for console messages.
Differential Revision: https://phabricator.services.mozilla.com/D153471
In the test, when fission isn't supported, we use Cu.reportError within
a SpecialPowers task, which puts the message in the console service cache.
If the test runs multiple time, the next iteration will run the test
with Fission support, which will consume cached messages, making the reportError
message appears more than we want.
This isn't a problem we can face in normal usage as when Fission is not supported,
we don't retrieve cached messages.
In order to fix the test failure, we simply clear the console service cache from
the content process.
Depends on D153327
Differential Revision: https://phabricator.services.mozilla.com/D153353
This should fix the intermittents
> TEST-UNEXPECTED-FAIL | devtools/client/aboutdebugging/test/browser/browser_aboutdebugging_addons_debug_storage.js | undefined assertion name - Got +0, expected 2
Note that there are other existing intermittents (timeouts mostly) which I have not investigated
Differential Revision: https://phabricator.services.mozilla.com/D153325
We remove all messages from target destroy with `isModeSwitching`, as well as
prune unhandled resources in the WebconsoleWrapper queues.
Finally, we also cleanup the resource command pendingEvents so we don't receive
resources after the target was destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D152031
We need to load the toolbox.ftl bundle and wrap the WebConsole App in a LocalizationProvider
when we're in the Browser Console.
Differential Revision: https://phabricator.services.mozilla.com/D150576
This adds an additional toolbar in the Browser Toolbox which will contain specific
tools and options.
At the moment we only display a couple input button to be able to switch from
Parent process only to multiprocess mode.
We remove the similar UI in the iframe picker and adapt the existing test.
A trait is added to not show the toolbar when debugging server where we wouldn't
get the `isSwitchingMode` property in `onTargetDestroyed`, as this can cause
misbehavior in various tool when switching between different modes.
Differential Revision: https://phabricator.services.mozilla.com/D150575
We remove all messages from target destroy with `isModeSwitching`, as well as
prune unhandled resources in the WebconsoleWrapper queues.
Finally, we also cleanup the resource command pendingEvents so we don't receive
resources after the target was destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D152031
We need to load the toolbox.ftl bundle and wrap the WebConsole App in a LocalizationProvider
when we're in the Browser Console.
Differential Revision: https://phabricator.services.mozilla.com/D150576
This adds an additional toolbar in the Browser Toolbox which will contain specific
tools and options.
At the moment we only display a couple input button to be able to switch from
Parent process only to multiprocess mode.
We remove the similar UI in the iframe picker and adapt the existing test.
A trait is added to not show the toolbar when debugging server where we wouldn't
get the `isSwitchingMode` property in `onTargetDestroyed`, as this can cause
misbehavior in various tool when switching between different modes.
Differential Revision: https://phabricator.services.mozilla.com/D150575
Previously when closing the breakpoints panel in secondary panes,
if an unselected call stack frame was selected, the breakpoints
panel would unexpectedly open. This patch makes sure it remains
closed when a user has closed it and then clicks other elements
in the secondary panes. The same issue was happening when
clicking the event listener breakpoint log checkbox, and or step
in, step out, and step over. This patch should also fix
Bug 1755337.
Add mochitest.
Fix mochitest issues and move isFrameSelected to shared-head.js
Fix linting issues.
Merge new mochitests into browser_dbg-state-based-panels.js
Add condition to SecondaryPanes/index.js
Add PropTypes to index.js
Add logic to reducers/pause.js
Add selector to selectors/pause.js
Add breakpointsPane action to pause/actions
Update mochitests to test for edge case
Remove dbg_browser-breakpoints-secondary-pane.js
Fix linting
Make changes suggest by reviewer
Add additional mochitest for event breakoints log
Remove unnecessary parameters from action
Fix mozbuild order
Remove previewPausedLocation.js from mozbuild to fix conflict
Differential Revision: https://phabricator.services.mozilla.com/D149994
We pass `isModeSwitching` to `unwatchTargets` from the target command when the
pref is changed.
On the server, we then pass it to the various places which might call `notifyTargetDestroyed`,
so we can pass the flag in the `target-destroyed-form` event, which we can then
pass to TargetCommand#onDestroyed callbacks.`
Differential Revision: https://phabricator.services.mozilla.com/D152758
Changes in Bug 1754407 caused a performance regression as it now triggered
syntax highlighting of big files, which we avoided before.
This is because we don't call `isMinified` with the expected type of data, causing
the file to not be seen as minified, and thus highlighting it.
Differential Revision: https://phabricator.services.mozilla.com/D153140
There are potentially several sources for the recent netmonitor intermittent failures.
One of them is that we have several helpers to "wait" for requests, and they have a logic so that when they spot a request, they will wait for the request to be
completed.
However if a navigation occurs in the middle, the corresponding resource will be cleared and the updates will not be processed.
So here we emit a test-only event when the netmonitor attempts to clear resources, so that test helpers can update accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D152726
This doesn't change anything. It actually complexify things a bit.
But this will be an helpful change we can do right away in order to help
create a unique Source object per URL (instead of per URL and target).
Differential Revision: https://phabricator.services.mozilla.com/D151553
This introduces a new reducer in order to maintain a Source Tree data structure.
A Source Tree is composed of:
* Thread Items
To designate targets/threads. These are the roots of the Tree if no project directory is selected.
* Group Items
To designates the different domains used in the website.
These are direct children of threads and may contain directory or source items.
* Directory Items
To designate all the folders. Note that each every folder has an items.
The Source Tree React component is doing the magic to coallesce folders made
of only one sub folder.
* Source Items
To designate sources. They are the leaves of the Tree.
(we should not have empty directories.)
See the creation methods in the reducer to see the various attributes available on each Item type.
Project root implementation has been simplified, but there is still subtantial complexity around it.
Also, there is a behavior change. Now the project root is thread specific,
whereas before it could be per domain/URL across threads.
The complexity of it is around preserving the `uniquePath` across reloads.
Because uniquePath starts with the thread actor ID, it can't be preserved across reload.
Instead, we replace the thread actor ID with "top-level" string.
This means that project root isn't preserved across reload for non-top-level targets.
About `uniquePath` attribute available on all items,
this will be the Path in ManagedTree and Key in Tree components.
i.e. a unique identifier for any item in the Tree.
The isWebExtension check is simplified to fetch it from the thread object,
instead of having to involve the "CONNECT" action.
Depends on D151467
Differential Revision: https://phabricator.services.mozilla.com/D150548
Update the test helper getRuleViewProperty to support an async version via a `wait` option.
When passed, the helper will keep polling until there is a valid ruleviewproperty which matches the arguments.
This can avoid race issues when the API is used too early.
In this changeset we also start using this API in all tests which either:
- used to manually poll getRuleViewProperty
- were disabled on linux for getRuleViewProperty issues
- are currently intermittent because of getRuleViewProperty
Differential Revision: https://phabricator.services.mozilla.com/D152286
