Issue:
- No indication for VoiceOver users that setting or removing breakpoints was triggered successfully
Changes:
- Adding ARIAUtils.alert call when setting/removing DOM breakpoints
Example alert string: "attribute modifications breakpoint removed"
For Narrator/NVDA:
For these SRs, sometimes the announcement string gets cut off due to the focus change to the selected DOM element. This is not too much of an issue because the SR will read "DOM Breakpoint <div class...>" after setting the breakpoint which counts as a success message for SR users.
For VoiceOver:
VO has the main accessibility violation since it reads "Closing menu page DOM table no selection" after adding/removing a DOM breakpoint without re-reading the selected DOM element. This alert will read clearly every time for VoiceOver.
Bug: 1197611
Change-Id: Iebd2b99132fae780df4a40ae0442bc161f8be05d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2817910
Commit-Queue: Michael Liao <michael.liao@microsoft.com>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Vidal Diazleal <vidorteg@microsoft.com>
Reviewed-by: Kalon Hinds <kahinds@microsoft.com>
This CL updates the theme colors doc so that the actual color values
come from CSS, so they don't get outdated. Additionally we now render
into a div that has the .-theme-with-dark-background class so that the
dark colors are rendered correctly too. Long term I'd like to generate
the entire list of variables automatically,but this is already an
improvement.
Bug: chromium:1152736
Change-Id: I89e44a9060fbef0866f670cced2030fdb2443526
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2853558
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Prior to this fix, the wasmparser_worker entrypoint would include
specific files from third_party/wasmparser. However, since the
files were included as part of a separate package, rolling up the
target could cause issues. They should have been part of the
`sources` of the wasmparser_worker entrypoint, but they were instead
included as `deps`. Even better would be to not include specific
files from the wasmparser and instead use an entrypoint.
In the specific case reported in crbug.com/1203165, the wasmparser
implementation was updated. As such, GN reran
`third_party/wasmparser` and determined that
`entrypoints/wasmparser_worker:wasmparser_worker` required
recompilation (since one if its dependencies were updated. However,
since `entrypoints/wasmparser_worker:wasmparser_worker` wasn't
producing a different output, GN would determine that it wouldn't
have to run rollup. This conclusion is wrong and is an artifact of
the inclusion of specific files of `third_party/wasmparser` by
the entrypoint.
To fix this, we should rollup all relevant sources in
`third_party/wasmparser` instead. That way, whenever the wasmparser
implementation is updated, it will properly roll up its content
into its bundle, ready for consumption by the entrypoint.
R=jacktfranklin@chromium.org
Bug: 1203165
Change-Id: Ic29ddea0d1f8e953e11e71a6a0e4e65c5f0f1ad6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2853559
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This locks down the visibility of ui/legacy:bundle to the various
folders that already depend on it. For now, the visibility is
quite broad, as there is still plenty of code depending on the
legacy UI implementation.
Consequently, downstream projects (such as the Edge DevTools fork)
will break if they depend on this bundle. Therefore, add a GN arg
that allows the visibility to be extended. To use this GN arg,
downstream projects can change their `default_args` in the root
`.gn` file:
default_args = {
devtools_ui_legacy_visibility = [
"//front_end/forked/folder/*",
]
}
This means that they can broaden the visibility of UI. It is still
recommended to remove as many of the dependencies on UI as feasible,
but that will likely not finish any time soon.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Bug: 1202788
Change-Id: I868e88ee3b1c66dd7c79d30d07648a7d2828e8f2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2853551
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
I was going to generate a CSS file for this but then I realised that
it wasn't so many that I couldn't do it by hand. Along the way I found
a few CSS selectors that I'm pretty sure are unused; I couldn't find
them when testing with a variety of console inputs, so I've removed
them. They also relied on CSS classes that I couldn't find references
to in `ConsoleView.ts`.
I've made liberal use of `--override-*` variables to get this file
migrated but will sync with Peter as I think some of these may be
legitimate color variables to pull into the theme colors.
Bug: chromium:1152736
Change-Id: I6bf5cab47d37b86bac5d820cf89c80d29bb999b9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2853546
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL makes Issue a generic class that takes a generic type for
the issue code. This type constrains the return type of Issue.code()
such that callers that, e.g. are dealing with a CorsIssue know that
the return values are coming from a particular enum value.
This allows to easily check that displaying code handles all codes.
One caveat is that the types cannot guarantee for IssueAggregator
that the aggregated issues are always of the same type although
this is the case. The reason is that this would require global
knowledge (we would have to know on the type level that no two issue
codes in subclasses of issues are the same).
Bug: chromium:1072335
Change-Id: I741e50db882636de314b79cd2109e2cb6efcf6e7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2848237
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Wolfgang Beyer <wolfi@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This reverts commit ecef9d5302.
Reason for revert: Suspected of causing deterministic build errors:
https://ci.chromium.org/ui/p/chromium/builders/ci/Deterministic%20Linux/30769/overview
The difference comes from gen/third_party/devtools-frontend/src/front_end/entrypoints/wasmparser_worker/wasmparser_worker.js
One build has: the line:
case 1:this._functionImportsCount=0,this._memoryImportsCount=0,this._tableImportsCount=0,this._globalImportsCount=0,this._eventImportsCount=0,this._functionNames=[],this._functionLocalNames=[],this._eventNames=[],this._memoryNames=[],this._typeNames=[],this._tableNames=[],this._globalNames=[],this._fieldNames=[],this._functionExportNames=[],this._globalExportNames=[],this._memoryExportNames=[],this._tableExportNames=[],this._eventExportNames=[];
The other build has:
case 1:this._functionImportsCount=0,this._memoryImportsCount=0,this._tableImportsCount=0,this._globalImportsCount=0,this._eventImportsCount=0,this._functionNames=[],this._functionLocalNames=[],this._memoryNames=[],this._typeNames=[],this._tableNames=[],this._globalNames=[],this._fieldNames=[],this._functionExportNames=[],this._globalExportNames=[],this._memoryExportNames=[],this._tableExportNames=[],this._eventExportNames=[];
Note that the first line I mentioned has an assignment to _eventNames, the second doesn't.
Original change's description:
> [deps] Update wasmparser to 5.1.1
>
> Includes the following upstream fix:
> a35948b fix: missing initializer in devtools name generator for exceptions
>
> Bug: chromium:1199329
> Change-Id: I7ebde5c42db4249a8cf264b540f6459d0db66a4b
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2850594
> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Bug: chromium:1199329
Change-Id: I773c2a79ce1f818acc766f450ed18dbb20bec4db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2851742
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
ProfileFlameChartDataProvider relies on its subclasses to set the
entryNodes property; one of the sub-classes was setting the
_entryNodes instead, resulting in the ProfileFlameChartDataProvider
behaving as if there were no nodes.
Bug: chromium:1199493
Change-Id: Ie7a4df160b8215fc7a97b0faccf692aac911b79d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2850593
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
When we intercept network requests for local overrides, we memorize the
original response and reuse that for the Changes panel. However, for
non-ASCII characters we didn't properly decode the Base64 encoded UTF-8
content, but assumed that the Base64 decoding would yield a valid String
itself.
Fixed: chromium:1091718
Change-Id: Idd0fa2626dfbcc8ac0e940461576a6a52e326a88
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2846325
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
This CL disables the InsecurePrivateNetwork issue for secure
contexts. This is in preparation for a new kind of private
network deprecation warnings: Requests from secure contexts
will require a preflight request in the future.
Bug: chromium:1141824
Change-Id: I6c0af48281f6cc8eb166a060a1651dc708f0157e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2848227
Reviewed-by: Wolfgang Beyer <wolfi@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
This change is to fetch userAgentMetadata and override navigator.userAgentData when user selects a pre-canned user agent from the network conditions tab.
Created 3 test scenarios to cover the userAgentMetadata values:
1) a device with userAgentMetadata and fixed userAgent value;
2) a device with userAgentMetadata and dynamic userAgent value where browser version is filled in dynamically;
3) a device without userAgentMetadata.
Bug: 1174299
Change-Id: If38cbb1f26784af890c86b7140b90899a6aa8504
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2832109
Commit-Queue: Guangyue Xu <guangyue.xu@microsoft.com>
Reviewed-by: Brandon Walderman <brwalder@microsoft.com>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: John Emau <John.Emau@microsoft.com>
Arno Renevier