This CL addresses an issue where datagrids could unexpectedly announce
content to screen readers if a grid node is selected when the grid
does not have focus - which can occur when a grid is first created.
This change limits datagrid alerts to when the grid has focus.
Repro steps in bug description.
Bug: 1164034
Change-Id: Ib6fd7012782f7073617ed20d5432333d83732ccb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2618379
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Brandon Goddard <brgoddar@microsoft.com>
This fixes a bug where if the user filters the network panel for the
text "foo", and filters by resource type (e.g. to "XHR"), when they
close and re-open DevTools the search text "foo" is persisted and added
back, but as a side-effect the resource type filter is lost.
I discovered this is true for all the additional filters; the moment you
restore a text filter every other setting is lost. To fix this we avoid
calling the `setTextFilterValue` function, which resets everything else,
and instead set the value of the filter input directly, with no other
side-effects.
Fixed: 1155564
Change-Id: I9fa1db634e9e5ec71e84b220c66503a4ab3e4be5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2577574
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
ui/Tooltip.js overrides the HTMLElement prototype to override the
title property. Rather than using this property, we shoul be
calling Tooltip.install directly. This makes sure that new
components are not relying on the behavior of the legacy
prototype patching.
These usages have been manually audited using the following regexes:
Search: ([\S]+)\.title = ([^;]+);
Replace: UI.Tooltip.Tooltip.install($1, $2);
Note that there are classes in DevTools that also have a title
property. Most notably `TreeElement`. We should not be replacing
these, as they do not inherit from HTMLElement. Luckily, we are
running TypeScript to make sure we don't call `Tooltip.install`
with a non-HTMLElement.
A follow-up CL will clean up the getters.
R=jacktfranklin@chromium.org
Bug: 1150762
No-presubmit: True
Change-Id: I5928e75c70293531849e0576f4fb2a2a8b3e02d2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2555060
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
As part of the dark mode migration we are adding
`enableLegacyPatching:true` to all call sites of `appendStyle` (and
related methods). If a user passes `false` for that flag, no CSS colour
patching will occur.
This CL is therefore a no-op from a user's perspective as we pass `true`
on every call to maintain existing behaviour, but once we start
migrating we will turn the option to `false`. Long term, once all code
is migrated and the old patching is removed, we will remove this flag
entirely once again.
Bug: 1122511
Change-Id: I76b818e83b7d5ee0175e1548759373f53481e0ab
No-Presubmit: True
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2516345
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
The network panel previously reported requests that failed due
to CORS as simply failed. This CL reports them as CORS error,
together with showing the error code on hover. This alone already
vastly improves the experience, and follow-up CLs will add detailed
descriptions of the problems.
Screenshot: https://imgur.com/a/LqXNmnP
Bug: chromium:1141824
Change-Id: I8a56d2c6c804e1d7d9e21c1866b5404dc3e18217
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2505906
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Wolfgang Beyer <wolfi@chromium.org>
This file was using `Headers` as iterable. This class is iterable,
but TypeScript didn't like it. As it turns out, there are multiple
definitions of the `dom` and `webworker` APIs. To get the iterable
versions, we have to add them explicitly. Therefore, also update
our TypeScript configuration to add the iterable variants.
DISABLE_THIRD_PARTY_CHECK=TypeScript fix
R=szuend@chromium.org
Bug: 1011811
Change-Id: Iae32bbf25d55346081dc2e0ab4f4093b531f91a1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2421705
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL adds a new url: filter to the network tab that filters
on the full URL, including the protocol information (e.g. https://)
in the search query.
Note on default filtering: Originally this CL modified the default
filtering by using the full request url, instead of the current
implementation which relies on the request path and name. Since this
change might have confused power-users and a more thorough rework
of the filtering is planned, the decision was made to add an additional
url: filter instead.
Bug: 1104188
Change-Id: Ibddd26eca7fb56eb9d08277df72c0da3acbb53a1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2318146
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
The web platform has :focus-visible now which does this for us.
https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible
A previous CL changed all of our CSS selectors over to rely on
focus-visible instead.
For the use cases where we called markAsFocusedByKeyboard() manually
from UI components, these still work as intended because the
:focus-visible implementation tracks this for us so manually
focusing the element with .focus() will still result in :focus-visible.
The elementIsFocusedByKeyboard() calls were replaced by checking if
:focus-visible is on the element or not. This is not a very good way
to do this, but fixing it is outside the scope of this CL.
Change-Id: I429adf7b1e7d8a8f2520cc75d0e8a0e50cfada32
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2352239
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Kalon Hinds <kahinds@microsoft.com>
Reviewed-by: Brandon Goddard <brgoddar@microsoft.com>
This CL uses structured cookie information in many places in
DevTools instead of re-parsing headers. This fixes a couple of
inconsistencies and glitches.
The remaining usage of the cookies parsed from the header
is in the HARLog class, where a layout test prevents us
from fixing it right now, see crbug.com/1079234.
DISABLE_THIRD_PARTY_CHECK=dependency, remove before committing
Bug: chromium:1027752, chromium:1051163, chromium:1057451
Change-Id: I967cd6cd73e234a52ae8ad0b7e5ecdcfc3608fc9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2187773
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL adds a central singleton that collects all issues from all
known targers. This singleton is then used by the issues view to
display issues.
This change enables correct handling of issues that arise from OOPIF
and worker sources.
Fixed: chromium:1073797
Change-Id: I75a8bb46d240f63df013c0b06506cad7fb2e5a8f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2168885
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
There are a few parts of the UI that assume that shortcuts will only be
one key (e.g. the shortcut tooltips displayed for some buttons), so this
CL updates them to access a new KeyboardShortcut.title() method to get
the name of a shortcut rather than just getting the name of a single
keypress from its Descriptor. The current/legacy Shortcuts settings tab
was one of these places, but I left it alone because it will be
obsoleted by the new custom shortcuts tab in the future and in the
meantime the only users who will have any chords enabled in the DevTools
will be those who have opted in to the custom shortcuts experiment and
enabled VS Code shortcuts.
Custom shortcuts doc: https://docs.google.com/document/d/1oOPSWPxCHvMoBZ0Fw9jwFZt6gP4lrsrsl8DEAp-Hy7o/edit#
Bug: 174309
Change-Id: Ic56fb14129a417ed441fc46401af226db52c8905
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2158086
Commit-Queue: Jack Lynch <jalyn@microsoft.com>
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
This CL fixes a bug where clicking on a search result in the network
tool would not properly reveal nodes if they were in a collapsed
group frame node.
Viewport datagrids do not actually attempt to reveal nodes that are not
attached on the root node flatlist - such as when a
parent node is collapsed. This fix allows newtwork nodes being revealed
to check if their parent is a frame node, and expand if so, allowing the
datagrid to properly reveal and select the node.
This bug originated when separating selection from opening the sidepane,
as attempting to open the sidepane on a frame node child would cause the
parent frame to expand. Which effectively "hid" this behavior until
selection no longer opened the sidepane.
See the bug description for good repro steps/site.
Bug: 1068747
Change-Id: Ie491a8f82286376fa50dd9922b16c44d6737c0a1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2141147
Commit-Queue: Brandon Goddard <brgoddar@microsoft.com>
Reviewed-by: Shane Clifford <shanejc@microsoft.com>
Reviewed-by: Jack Lynch <jalyn@microsoft.com>
This CL fixes an issue that causes the network Log area to receive
a focus indicator when the "Learn More" link is focused/clicked.
This issue was caused because the logic to trigger the focus ring
on the network log area assumed the only focusable content within the
container was the DataGrid. It previously showed the ring whenever
focus was within the container and the datagrid did not have a request
selected.
Now it only shows if the datagrid receives focus and does not have
a node selected.
(Note that this focus logic was included because the
waterfall column is not part of the Datagrid)
Before: https://imgur.com/2cGS207
After: https://imgur.com/LzEDWBW
Bug: 1056138
Change-Id: I5c1f5fd03b5ed674f27c5b591fc76cfa4d46d165
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2120649
Reviewed-by: Jose Leal <joselea@microsoft.com>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Brandon Goddard <brgoddar@microsoft.com>