With https://crrev.com/c/3093151 we made it such that whenever we show
object properties, we'd always show the own properties first, followed
by the inherited properties. Even before that, the object display would
already put more emphasis on enumerable properties. So generally the
order within DevTools front-end is:
(1) Own enumerable properties
(2) Own non-enumerable properties
(3) Inherited enumerable properties
(4) Inherited non-enumerable properties
The JavaScript autocompletion for object properties wasn't following
this pattern, but was only sorting own before inherited properties. With
this change, the autocompletion will now favor enumerable properties
over non-enumerable properties, when computing the fuzzy score.
Before: https://imgur.com/Y2JmJwZ.png
After: https://imgur.com/qGEMa8L.png
Fixed: 1299241
Change-Id: Ibd42da9cf6d2947803d2cc0eca1f67f2f3ada55d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3645453
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
This CL adds the ability to create header overrides from the list of
network requests in the network panel via the context menu.
If a local folder for storing local overrides has already been
configured beforehand, the context menu takes the user straight to the
'.headers' file where header overrides are to be specified. If
overrides have not been configured before, the user has to name a
local folder for storing overrides first.
Video: https://i.imgur.com/kLGlOtL.mp4
Bug: 1297533
Change-Id: I8b31fe41d922e1662da68320fcc188c596c0a058
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3542245
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
The description here is vague, but because the issue includes both a reference to the original request and the invalid header value, it
should still be more useful to developers than the situation before this
CL, which was for invalid headers to be silently ignored.
We will add additional metadata, such as the name of the invalid header
and the reason why it was invalid, in future changes.
Screenshot of reported issue available in crbug.com/1302318#c4.
Bug: 1302318
Change-Id: Ie7f3b5e34b25ff56d832bf553ffcac674b5a57ba
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3644629
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
This regressed with https://crrev.com/c/3310606 where `SPAN_IDENT` was
introduced as a filter for properties to show in the autocompletion box
when using the dot MemberExpression syntax. The `SPAN_IDENT` regex looks
wrong and unnecessarily complicated.
This change uses the ID_Start and ID_Continue unicode property escapes
instead, so we get the right match here.
Fixed: 1324466
Bug: 1275553
Change-Id: I6f0d57771a7370ca761df8a62d488586992e9e3a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3644947
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Adding a sandboxed file system via `window.webkitRequestFileSystem` to
hosted mode enables using local overrides in hosted mode. Since e2e-
tests run in hosted mode, this enables adding e2e tests for local
overrides. This CL adds a first such e2e-test testing a simple response
header override.
Bug: 1313436
Change-Id: I6eb3e2ff9de336fa62648647fe48042009743d18
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3620364
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
This CL removes a race that may happen if PersistenceImpl tries to
move a breakpoint from one UISourceCode to another UISourceCode by
explicitly awaiting the calls to remove/setBreakpoint in
PersistenceImpl.
The race happens in the following case (affecting snippets):
* A snippet is created, and the user sets a breakpoint and reloads
the page.
* PersistenceImpl.ts will try to move the breakpoint via
1. removing the breakpoint from the old UISourceCode, and
2. re-setting the breakpoint on the new UISourceCode.
* Simultaneously, the BreakpointManager tries to set a breakpoint
on the new UISourceCode
* For snippets, the url stays the same after reloading, and in some
cases the `setBreakpointByURL` of the PersistenceImpl and the
BreakpointManager will be sent to v8 one after another, such that
v8 returns a ServerError, as it has already set the breakpoint
previously
This race causes the breakpoint to completely disappear, since
DevTools front-end removes the breakpoint if it sees a ServerError.
Drive-by: Added additional clean up step to tests.
Bug: 1280621
Change-Id: I7c9cd94c02d80661100cc5c5141e7d0dbb027f6d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3629862
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
The CL https://crrev.com/c/3613872 applied some weird formatting to
the UIStrings object of DeprecationIssue.ts. This then caused the
strings to be no longer collected by our l10n infra (the CL removes
them from en-US.json).
This CL fixes that by turning off clang-format in that file and let
the PRESUBMIT script re-populate en-US.json with the UIStrings from
that file.
We have not yet imported these strings into the TC, so we were
lucky in catching this early.
Bug: None
Change-Id: I05b9faca446e19ff57ef3eccd04e919234797f8d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3635181
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Previously, the button, scroll element into view is broken, and UI has
overlay.
This CL
1. Fix button scroll element into view feature.
2. Add style to improve UX (see screenshots).
How to test (or see video record):
1. Go to twitter.com
2. Resize Chromium window to smaller height
3. Open devtools and generate CSS Overview report
4. Go to "Font info" -> scroll to "line-weight" -> select "16px" item
5. Hover on first row and click the button on the right side
6. Twitter page should scroll to bottom, to target Element
Video record:
- https://www.youtube.com/watch?v=rhTwLUiMbss
Before vs After screenshot
- https://imgur.com/a/Z4s0KoB
Bug: 1321076
Change-Id: I9069fd789ef820411ec0ece3f6efb24d84247119
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3631623
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Commit-Queue: Changhao Han <changhaohan@chromium.org>
Add a toggle that enables / disables large blob support for WebAuthn
virtual authenticators. This feature has been long supported by the
devtools protocol but we hadn't surfaced it on the front-end.
Large blobs are only available for resident-key enabled authenticators,
so we disable the checkbox if that option is not selected. Also, large
blobs require CTAP 2.1.
Fixed: 1321803
Change-Id: Ic1654276ba5a39ddd8943cd8689978117546e70e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3625237
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Nina Satragno <nsatragno@chromium.org>
Auto-Submit: Nina Satragno <nsatragno@chromium.org>
Previously, user able to generate Lighthouse report when JavaScript is
disabled, UX is bad.
This CL, disable "generate report" feature when Javascript is disabled.
How to test:
1. Go to "www.google.com"
2. Open devtools -> Lighthouse tab
3. Open "Command Menu" and disable JavaScript
4. Check Lighthouse UI, the "generate report" button should be disabled.
The warning message should show up.
5. Open "Command Menu" and enable JavaScript
6. "generate report" button should be enabled
Screenshots
- https://imgur.com/a/VYPLal1
Video record:
- https://youtu.be/oSMjjMfT4_k
Bug: 1319400
Change-Id: Ibfbae1961bf86c0beedb5d77ceff94152c6e2df3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3622736
Reviewed-by: Paul Irish <paulirish@chromium.org>
Reviewed-by: Adam Raine <asraine@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
This fixes the character encoding of the UrlString returned by
`urlsFromParentUrlAndName()`, which is called by `WorkspaceImpl`'s
`renameUISourceCode()`, to match the encoding of filenames as they are
received via `fileSystemFilesChangedAddedRemoved()` from the backend.
Without a matching encoding, the UISourceCode will not be found when
looking it up by URL, which in turn leads to the creation of an
additional duplicate UISourceCode.
Fixed: 1320717
Change-Id: I39a6bda366da3ee681a77f28bb1ad3bcccc86fa5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3613869
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Eric Leese <leese@chromium.org>
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
Instead of trying to set inspectedURL for child targets (which might
confuse extension server), we just lookup the containing frame's url
locally in the source map manager whenever we need it for resolving
relative paths.
This might flush race problems (because inspectedURL is set
asynchronously after receiving getResourceTree response), but such
problems were there before. They are not easy to fix without
redesigning how we index source maps in source map manager's
internal data structures (and they are even harder to repro
and test).
Bug: chromium:1305475
Change-Id: I9e9b67ca1353b4707542f3931db0aef821c00f41
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3613885
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Jacky Hu
