When the last visible message was an evaluation result
but the last message in the store was something else,
the console would trigger the pin-to-bottom behavior.
This is fixed by checking if the last message in the
store (and not the last visible message) is a result.
A test case is added to make sure we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D150225
persistTabs should only be used when we want to clear the tabs list
and have the persisted tab to be re-created (made visible, with a sourceId) when a new source matching the same url is created.
Also cleanup a few things and avoid returning new state objects unless we really changed something.
Differential Revision: https://phabricator.services.mozilla.com/D149523
The link was missing an event listener, that we add in this patch.
A test case is added to make sure the link does work.
Differential Revision: https://phabricator.services.mozilla.com/D149953
I could reproduce the intermittent locally and when it occurs, the initial editor actually didn't have focus.
I think that what happens is that we hit a race condition where the focus is stolen by the initial editor after we clicked on a new stylesheet
and switched to a new editor.
Differential Revision: https://phabricator.services.mozilla.com/D149952
For `--backgroundtask ... --jsdebugger` invocations, the devtools
profile is kept inside the ephemeral background profile. This means
that breakpoints, etc are not preserved across repeated debugging
invocations. This change eases the debugging process.
Differential Revision: https://phabricator.services.mozilla.com/D145893
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
This fixes an intermittent on browser_webconsole_warn_about_replaced_api.js where
an assertion was failing because the navigation message had the `console-api` class.
We take this as an opportunity to add a navigation marker specific component instead
of reusing the ConsoleApiCall one.
Differential Revision: https://phabricator.services.mozilla.com/D149739
This only fail on MBT because it still uses non-EFT
and the top level document is displayed in the iframe dropdown
via the old "listFrames/frameUpdate" codepath.
So that its frameData's id isn't related to a target actor
but rather to a frame of the parent-process/window-global target actor...
I'm adding test coverage for the regular web toolbox,
but the fix only reproduce in the context of the browser toolbox.
Depends on D149257
Differential Revision: https://phabricator.services.mozilla.com/D148793
This add some minimal test coverage for the UI bits.
But more detailed test should rather be done around the TargetCommand API (browser_target_command_scope_flag.js).
Depends on D149256
Differential Revision: https://phabricator.services.mozilla.com/D149257
When passing an array, only booleans and number were accepted.
Also arrays were stringified to list of value coma separated,
as if arrays were refering to list of arguments.
That while passing a primitive value would be passed as a unique argument.
Clarify this by explicitely accepting arrays refering as list of argument,
or a primitive value being a unique argument.
I'm also fixing an issue with exceptions not being correctly reported.
Depends on D148527
Differential Revision: https://phabricator.services.mozilla.com/D149256
This introduces a checkbox in the iframe dropdown to enable/disable multiprocess debugging live.
Switching between:
- debugging only the main process (all documents, workers and priviledged JS)
- debugging all the processes (same, for each process, we will debug documents, workers, JS, ...)
This helps significantly speed up the browser toolbox when debugging only parent process resources,
while still allowing to switch to debug everything when required.
Depends on D146891
Differential Revision: https://phabricator.services.mozilla.com/D148527
We don't have a toolbox in the Browser Console, so we don't
need to have a Provider for its store.
A simple test is added, just checking that the action was
triggered.
Differential Revision: https://phabricator.services.mozilla.com/D149593
Delay computing the CSS changes until the declarations have been updated to reflect the values understood by the engine.
This avoids trusting authored values for CSS changes, and fixes all scenarios where users typed an opening character (single quote, double quote etc...) or an escape
character.
Differential Revision: https://phabricator.services.mozilla.com/D149603
This only fail on MBT because it still uses non-EFT
and the top level document is displayed in the iframe dropdown
via the old "listFrames/frameUpdate" codepath.
So that its frameData's id isn't related to a target actor
but rather to a frame of the parent-process/window-global target actor...
I'm adding test coverage for the regular web toolbox,
but the fix only reproduce in the context of the browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D148793
This add some minimal test coverage for the UI bits.
But more detailed test should rather be done around the TargetCommand API (browser_target_command_scope_flag.js).
Differential Revision: https://phabricator.services.mozilla.com/D149257
When passing an array, only booleans and number were accepted.
Also arrays were stringified to list of value coma separated,
as if arrays were refering to list of arguments.
That while passing a primitive value would be passed as a unique argument.
Clarify this by explicitely accepting arrays refering as list of argument,
or a primitive value being a unique argument.
I'm also fixing an issue with exceptions not being correctly reported.
Differential Revision: https://phabricator.services.mozilla.com/D149256
This introduces a checkbox in the iframe dropdown to enable/disable multiprocess debugging live.
Switching between:
- debugging only the main process (all documents, workers and priviledged JS)
- debugging all the processes (same, for each process, we will debug documents, workers, JS, ...)
This helps significantly speed up the browser toolbox when debugging only parent process resources,
while still allowing to switch to debug everything when required.
Differential Revision: https://phabricator.services.mozilla.com/D148527
At the end getDisplayedSources wasn't correctly memoized and generates new array instances
even if the content of the source tree doesn't change.
That's because internaly, it crafts an array which is always a new array instance.
Let's merge the two intermediate selectors into a single one so that we can more easily memoize it.
This should also help try to followup and attempt at generating the data structure needed for ManagedTree.
That, instead of generated the data for addToTree/updateTree which then feeds ManagedTree.
Differential Revision: https://phabricator.services.mozilla.com/D148526
The source tree seems to be updated asynchronously after the source selection.
Also, the SourcesTree component wasn't correctly selecting and expanding the tree
when the selected source was immediately selected as it gets created in the source tree.
Differential Revision: https://phabricator.services.mozilla.com/D148838
In the console we might receive messages that need to be inserted at a specific
position in the output to respect the chronological order.
This is very visible when evaluating an expression in the console while we are
fetching cached messages, or when the expression is logging lots of messages, since
the evaluation result doesn't go through the ResourceCommand itself.
Since we were relying on the order of insertion in `mutableMessagesById` for the
order of messages in the output, we had no choice but clone the Map to insert
the new message at the specific position.
With lots of messages, this can be utterly slow, and is something people are experiencing.
To fix this, we're adding a new state property, `mutableMessagesOrder`, which holds
message ids in the chronological order. It's then used to compute `visibleMessages`.
As we don't have to clone the Map anymore, it makes reordering as fast as looking
for an index in the array and splicing it (which is fast).
We also take this opportunity to switch away from our `findIndex` usage; most often
than not, the messages will be reinserted at the end of the array, so we can loop
through it backward to find the index faster.
We still keep `mutableMessagesById` as a Map so lookup are fast, and we don't have
to deal with impacts we'd have if we'd switch to an object.
The existing node test helper to get a message at a specific index are migrated
to make use of `mutableMessagesOrder`, and a few test cases and assertions are
added to check that the new property is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D148658
The source tree seems to be updated asynchronously after the source selection.
Also, the SourcesTree component wasn't correctly selecting and expanding the tree
when the selected source was immediately selected as it gets created in the source tree.
Differential Revision: https://phabricator.services.mozilla.com/D148838
These two DevTools DOM panel tests are expecting the elements being inspected to be at a certain row index
which depends (likely due to alphabetic order) that InstallTrigger is listed as a global in the window
being inspected (it doesn't matter what the value is, the failure is triggered because when InstallTrigger
is completely hidden the elements expected by the tests are shift by one row position).
And so these two tests would be currently permafailing when "extensions.InstallTrigger.enabled" is set to `false`
(but they are completely uneffected when "extensions.InstallTriggerImpl.enabled" is set to `false`, because the
InstallTrigger global is still defined, just set to null instead of providing the API defined by the
InstallTriggerImpl interface).
This patch changes name of the global properties to which they are set to "A" and "B", to make sure those properties
are going to be in rows listed in the DOM panel before the two non-standard globals `InstallTrigger` and `SpecialPowers`
and so that the visibility of the InstallTrigger global (either disabled or still visible) doesn't affect the test case.
Differential Revision: https://phabricator.services.mozilla.com/D148975
Changing the pattern for toggling recording to ensure that pause/resumes actually
start or stops watching resources before the ui states gets updated.
Differential Revision: https://phabricator.services.mozilla.com/D148953
Depends on D148489
This allows to properly set the cssErrorReportingEnabled flag on its docShell.
While we are not interested in css errors for this fallback window, the windowglobal target actor
will automatically set the flag on new root browsing contexts only if the previous one had the flag
set. This way when we switch to a valid webextension document (eg a popup), the flag will be set
and CSS errors will be reported.
Differential Revision: https://phabricator.services.mozilla.com/D148836
This window does not share the regular extension principal so we cannot fetch
the addonId from the principal in the same way as we do for other documents.
Instead we append the addonId to the URL and provide a new helper in browser-context-helpers
to extract the addonId from a browsingContext.
This helper should work transparently from the parent process and the content process, and
should support browsing context for regular extension documents as well as browsing contexts
for fallback windows.
Differential Revision: https://phabricator.services.mozilla.com/D148489
We use to transform expression like `await obj` into
```
(async () => {
return await obj;
})()
``
So we were basically returning the expression, wrapped in an async iife, adding
a `return` statement before the last statement.
But in the case the last statement is an `AwaitExpression`, we can simply return
the argument, stripping the `await` keyword.
This fixes an issue when awaiting for an object with a `then` getter would execute
the getter twice.
A test case is added in mochitest, and unit test are updated to reflect the new
output.
Differential Revision: https://phabricator.services.mozilla.com/D148806
Since Network monitoring is switched of by default in the browser console, we need to
switch it on explicitly for the browser_console_context_menu_entries.js test.
Differential Revision: https://phabricator.services.mozilla.com/D148776
This helps compute it only once per source and help simplify the updateTree layer.
We no longer have to path thread/mainThreadHost everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D147780
We were using `isInvalidUrl` late in the process of updateTree layer to ignore sources
and prevent displaying them in the SourceTree.
But getDisplayedSources is dedicated to the SourceTree and can eagerly filter out the right sources
right away.
Also getDisplayedSourceIDs is already accepting only source with a URL,
so we don't have to recheck if the source is having a URL.
I extended mochitest test coverage to replace the removed jest tests.
Differential Revision: https://phabricator.services.mozilla.com/D147777
At the end, we weren't using the url but only the host.
And "debuggee" is pretty vague, let's clarify with "main thread".
Differential Revision: https://phabricator.services.mozilla.com/D147762
Before, only "shown source" would really expand the tree to show the source in tree,
whereas "highlight" would only highlight the folder that is opened
(in case the source isn't visible and folder isn't expanded).
But when we select a new shown source, we also update the selected location,
which also changes the highlight items.
It is significantly clearer to only have "selected source" and have the SourceTree
to automatically expand the tree and show the selected source.
(Also a sneaky call to .reverse() was mutating the `highlightedItems` props...)
Differential Revision: https://phabricator.services.mozilla.com/D147759
The safe mode dialog will be displayed instead of the browser toolbox when the previous browser
toolbox has been closed too brutaly. This happens every now and then.
Also, when you opened a URL from the browser toolbox, this will then trigger a transient
browser window that appears and immediately disappear when opening the browser toolbox
all next time you start it. It might be related to session restore, but it looks like it is not enough
to get rid of this blinking window.
Differential Revision: https://phabricator.services.mozilla.com/D148515
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
The multiprocess browser toolbox is on by default in BETA, so we
need to switch it on explicitly for the addon extensions to be listed.
Differential Revision: https://phabricator.services.mozilla.com/D148392
Highlights
- Network monitoring is turned off by default in browser console/ browser toolbox console on initial load.
- A new "Enable Network Monitoring" setting is added to enable users toggle on an off as they desire.
- The user setting is persisted across toolbox reopens.
Differential Revision: https://phabricator.services.mozilla.com/D145234
The devtools.browsertoolbox.fission should not be read on the server but should instead be provided to the server by the client.
The breakage can be reproduced if you try to debug a Firefox desktop with devtools.browsertoolbox.fission = false from a Firefox with devtools.browsertoolbox.fission
= true.
Differential Revision: https://phabricator.services.mozilla.com/D148129
Either of the two changes fixes the reported issue.
On the frontend side, we weren't listening to DevToolsClient/connection close.
So that there was no guarantee that the Browser Toolbox would close if the remote connection is lost.
We were actually depending on Launcher.close to be called (it is called correctly)
and complete `dbgProcess.kill()`, which apparently doesn't always work during shutdown.
It looks like `SubProcess.kill` was made slower and didn't always had time to complete
because on the server side, the Parent Process Target actor was trying
to switch from browser.xhtml to chrome://extensions/content/dummy.xhtml.
But this document is being destroyed and the target as well as all children
actors and watchers were still trying to debug stuff and were all throwing.
Correctly destroying the parent process target actor when browser.xhtml is closed
seems to allow SubProcess.kill to complete...
And thanks to client's closed listener, even if we stop killing the process,
the browser toolbox process will close by itself.
Differential Revision: https://phabricator.services.mozilla.com/D148128
Highlights
- Network monitoring is turned off by default in browser console/ browser toolbox console on initial load.
- A new "Enable Network Monitoring" setting is added to enable users toggle on an off as they desire.
- The user setting is persisted across toolbox reopens.
Differential Revision: https://phabricator.services.mozilla.com/D145234
We were instantiating one new Loader per DevToolsFrameChild instance.
This patch tries to share this loader with all the instances as well as share it
with the one used to load DevToolsServer when we are running in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D147257
When resources related to a given Target are notified via the Watcher actor,
we have to ensure waiting for the TargetFront to be fully initialized.
That's because code watching for resources expect the target front to be attached
and have its thread front already available.
Differential Revision: https://phabricator.services.mozilla.com/D143408
Wait for the cursor to be set.
We take this opportunity to inline the functions that were only called once,
as well as refactor a few things to make the test easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D147259
The selector is already sorting the breakpoints,
so there is no need to re-sort them in the component.
Also Array.sort(stringA-stringB) was misbehaving.
Then I'm using getSourcesMap in order to avoid calling getBreakpointList many times.
Otherwise getSourcesForBreakpoints has to receive the state object
in order to retrieve the source objects.
Differential Revision: https://phabricator.services.mozilla.com/D146426
breakableLines wasn't correctly memoized for sources other than the original ones.
This patch at least fix this for regular JS files sources, but the issue still
happens for HTML sources having more than one source actor.
Differential Revision: https://phabricator.services.mozilla.com/D147195
In the frontend we end up having special sources, related to many source actors.
These are the sources for HTML pages, which have one unique source object.
But each inline <script> tag will have its own source actor.
All these sources actors will be bound to this unique source for the HTML page.
Differential Revision: https://phabricator.services.mozilla.com/D144412
The characteristics of the throttling profile are not really accessible anywhere.
At least having them in the button title can help.
I started reorganizing throttling profiles as instances of a ThrottlingProfile base class, because
that should be useful when we implement custom profiles
Differential Revision: https://phabricator.services.mozilla.com/D147131
In the frontend we end up having special sources, related to many source actors.
These are the sources for HTML pages, which have one unique source object.
But each inline <script> tag will have its own source actor.
All these sources actors will be bound to this unique source for the HTML page.
Differential Revision: https://phabricator.services.mozilla.com/D144412
The selector is already sorting the breakpoints,
so there is no need to re-sort them in the component.
Also Array.sort(stringA-stringB) was misbehaving.
Then I'm using getSourcesMap in order to avoid calling getBreakpointList many times.
Otherwise getSourcesForBreakpoints has to receive the state object
in order to retrieve the source objects.
Differential Revision: https://phabricator.services.mozilla.com/D146426
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
There's an issue in React 16 that only occurs when MessageChannel is available
which prevents the nodeJS process to exit.
MessageChannel support was added in Node 15, so when we try to update to Node 16,
it caused a problem in CI.
Differential Revision: https://phabricator.services.mozilla.com/D146906
We already have translation strings in `device.properties`, so we can use them.
String for `custom` type was missing, so we add it.
Assertions are added in test to check that we do have the expected labels in the UI.
Differential Revision: https://phabricator.services.mozilla.com/D146784
Two tests had to be changed.
The first test had to be changed because I removed redundant error message logging from requestStorageAccess and its network of helpers.
The second is because we were acting out-of-specification and stopping nested iframes from using the storage access API. I could have done this in a second bug, but I felt like doing it here made sense enough.
Depends on D146343
Differential Revision: https://phabricator.services.mozilla.com/D146344
In `viewSourceInStyleEditor`, we used to first load the styleeditor, and then
select the stylesheet and show the panel. This mean that when clicking on a location
from the rule view, there would be some delays before we show any feedback to the user.
Since the load promise for the panel only settles once we watched for all existing
stylesheets and loaded their content for each of them, it could take a while in
cases where we have lots of stylesheets, like in the BrowserToolbox.
So here we modify `viewSourceInStyleEditor` to directly select the styleeditor and
passing it a stylesheet that can be added right away, in case the panel wasn't
loaded yet, without waiting for the stylesheets to be watched.
We take this as an opportunity add a test when `viewSourceInStyleEditor` is called
with a stylesheet not used on the page, and check that it does open a view-source tab.
Differential Revision: https://phabricator.services.mozilla.com/D146540
Just testing that the editor and the new label work as expected since
these are the things that I could find broken in my reduced examples.
Differential Revision: https://phabricator.services.mozilla.com/D146688
This just intends to alleviate the more noticeable problem when the cache grows
too large by avoiding iterating through the array every time something changes.
There still remains the work of limiting the size of this based on what the UI
is capped at, but that can come later.
Differential Revision: https://phabricator.services.mozilla.com/D142279
I tried to pick thread groups that are part of GeckoView (Gecko), might be
common to GeckoView products (Nimbus), and the Android ecosystem (Kotlin
coroutines) instead of threads that are fenix-specific.
Differential Revision: https://phabricator.services.mozilla.com/D144753
The issue here is it seems like WebExtensionPolicy is not always available on the Cu global,
therefore failing when trying to get the extension policy name.
in this example when adding sources from the browser toolbox (i'm still not completely sure why)
The solution here is changing to using the ExtensionProcessScript which works for the web and browser
toolbox.
Also added a `console.warn` so we get some notification when this fails.
Differential Revision: https://phabricator.services.mozilla.com/D144787
The test was only waiting for addTab to resolve, waiting for the proper toolbox-ready event could reduce intermittent issues.
Differential Revision: https://phabricator.services.mozilla.com/D146530
If the walker actor was initialized, we assume the document is ready enough and a root node can be returned if available.
A new test was added for a slow loading document.
Differential Revision: https://phabricator.services.mozilla.com/D146464
This `global` variable is used for accessing Error prototypes, and they're
properties of the shared global (`globalThis`), not per-JSM global (`this`).
Differential Revision: https://phabricator.services.mozilla.com/D144131
This tries to fix a race issue where, on reload, the pause event fires way before the
related source is available. This is an issue the had the potential on happening at some point.
This fix is not super perfect but with the trottling of sources there is no guurantee that sources will
always be available before pause event fires.
This pattern is also used for source actors. waitForSourceActorToBeRegisteredInStore.
Differential Revision: https://phabricator.services.mozilla.com/D145925
The command requires having network resource command support,
which is still not enabled everywhere (e.g. non-multiprocess browser toolbox).
We simply remove the backward compat comment but leave the check on network
resource command support.
Differential Revision: https://phabricator.services.mozilla.com/D145890
This removes FlameGraph.js, Graphs.js, GraphsWorker.js, LineGraphWidget.js, MountainGraphWidget.js
and their related tests.
DevToolsWorker tests that were relying on GraphsWorker.js are updated to use a test-specific blob worker.
Differential Revision: https://phabricator.services.mozilla.com/D145462
We using Ctrl|Cmd+P as Ctrl|Cmd+F is used for a in-file search in
the CodeMirror instance.
We're tesing the keyboard shortcut in browser_style_editor_filter.js
by using it instead of manually calling input.focus and clearing it
programatically.
Differential Revision: https://phabricator.services.mozilla.com/D145057
For some reason, the new test added in the previous patch has an impact on this test:
when checking the disk cache, there's a `mochi.test:8888/tests.json` entry, and
since the test was only checking if there was an entry with the `mochi.test:8888` entry,
it was failing.
I wasn't able to understand why we have this entry in the cache, but it reveals
that the test check is a bit too broad, since what we cares about is simply to
know if the fetched stylesheet was added in the disk cache.
So here we're doing just that, checking that the fetched stylesheet wasn't added
to the disk cache.
Depends on D144723
Differential Revision: https://phabricator.services.mozilla.com/D145344
The patch adds a filter input in the xhtml file, which will filter the list
of stylesheets displayed on the left side, based on the stylesheet name.
If the active stylesheet is filtered-out, the first visible one gets selected.
If all the stylesheet are filtered-out, a label is displayed indicating that
the search doesn't match any stylesheet.
The splitview CSS already had rules for this behaviour, so we're reusing what's
already there, re-adding the placeholder for the "all filtered" message.
This had an impact on keyboard navigation; the list is sorted by `ordinal` property,
which drives a `MozBoxOrdinalGroup` style property (similar to `order` on a flex item).
The navigation used to simply get the active ordinal, and move to the next one.
Now, the "next" ordinal could be hidden, so we change the behavior to move the focus
to the next (or previous), visible item in the list.
A test is added to check that everything works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D144723
See the comment in the file explaining it. For a case of logging 100k numbers,
this dropped the time per number from 15 microseconds to 9 with the console
closed, and 55 microseconds to 38 with the console open. I think we could shave
off more with a native approach, but I don't know that it's worth it and it's
much more likely for that to introduce bugs.
Differential Revision: https://phabricator.services.mozilla.com/D143782
The patch adds a filter input in the xhtml file, which will filter the list
of stylesheets displayed on the left side, based on the stylesheet name.
If the active stylesheet is filtered-out, the first visible one gets selected.
If all the stylesheet are filtered-out, a label is displayed indicating that
the search doesn't match any stylesheet.
The splitview CSS already had rules for this behaviour, so we're reusing what's
already there, re-adding the placeholder for the "all filtered" message.
This had an impact on keyboard navigation; the list is sorted by `ordinal` property,
which drives a `MozBoxOrdinalGroup` style property (similar to `order` on a flex item).
The navigation used to simply get the active ordinal, and move to the next one.
Now, the "next" ordinal could be hidden, so we change the behavior to move the focus
to the next (or previous), visible item in the list.
A test is added to check that everything works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D144723
Nicolas Chevobbe
Florian Quèze
Joel Maher
Michael Ratcliffe
Alexandre Poirot
Julian Descottes
manekenpix
Nick Alexander
Emilio Cobos Álvarez
Mark Banner
Hubert Boma Manilla
Iulian Moraru
Zoltán Szatmáry
criss
Norisz Fay
Tetsuharu Ohzeki
Tooru Fujisawa
Luca Greco
colin_czb
Andrew McCreight
Molnar Sandor
Butkovits Atila
Gabriele Svelto
Andreea Pavel
Cosmin Sabou
Tom Schuster
Cristian Tuns
Benjamin VanderSloot
Doug Thayer
Michael Comella
Sebastian Hengst
Luke Swiderski
Greg Tatum
Feng Yu