This reverts commit 056ad78a21.
Reason for revert: Suspected to make e2e tests on the windows bot more flaky.
Original change's description:
> Reland: [e2e] Use pre-allocated DevTools and target tabs
>
> This CL relands https://crrev.com/c/3461563.
> The main difference is that while we enable the pool implementation,
> we configure the pool size to be 0 unconditionally. This way, we get
> the benefit of spinning up fresh DevTools and inspected tabs while
> preserving the old behavior of doing the setup of these tabs right
> before a test executes and not in the background.
>
> Original CL description:
> > [e2e] Use pre-allocated DevTools and target tabs
> >
> > This CL changes the conductor to use new DevTools frontend and target
> > tabs for each individual test. A pool prepares a set of frontend/target
> > tab pairs in the background so the conductor doesn't need to waste time
> > resetting tabs in between tests.
> >
> > For debugging e2e tests we disable the pool and use on-demand tab
> > creation instead. It would be annoying to deal with ~12 open tabs
> > and trying to find the right ones in a debugging session.
> >
> > This CL also increases the general e2e test timeout from 5 to 10
> > seconds. This is because of the more volatile nature of e2e tests
> > now. In some edge cases a tab for the currently running test might
> > not get enough CPU time to run in time. This can happen when a
> > serious of short running tests deplete the pool and multiple
> > Devtools frontend instances have to be prepared in the background.
> >
> > R=jacktfranklin@chromium.org
> >
> > Bug: 1297458
> > Change-Id: I6b6c4a15e5d83f7e2bdc6082972993df179a5d87
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3461563
> > Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> > Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
> > Commit-Queue: Simon Zünd <szuend@chromium.org>
>
> Bug: 1297458
> Change-Id: Iac0294116f1a9e762a3847bcb0738955bba957b2
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3641403
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Bug: 1297458
Change-Id: I4758c4c9cb3e7919f12bccc28c9310ab7225c729
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3645451
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Auto-Submit: Simon Zünd <szuend@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>
This CL relands https://crrev.com/c/3461563.
The main difference is that while we enable the pool implementation,
we configure the pool size to be 0 unconditionally. This way, we get
the benefit of spinning up fresh DevTools and inspected tabs while
preserving the old behavior of doing the setup of these tabs right
before a test executes and not in the background.
Original CL description:
> [e2e] Use pre-allocated DevTools and target tabs
>
> This CL changes the conductor to use new DevTools frontend and target
> tabs for each individual test. A pool prepares a set of frontend/target
> tab pairs in the background so the conductor doesn't need to waste time
> resetting tabs in between tests.
>
> For debugging e2e tests we disable the pool and use on-demand tab
> creation instead. It would be annoying to deal with ~12 open tabs
> and trying to find the right ones in a debugging session.
>
> This CL also increases the general e2e test timeout from 5 to 10
> seconds. This is because of the more volatile nature of e2e tests
> now. In some edge cases a tab for the currently running test might
> not get enough CPU time to run in time. This can happen when a
> serious of short running tests deplete the pool and multiple
> Devtools frontend instances have to be prepared in the background.
>
> R=jacktfranklin@chromium.org
>
> Bug: 1297458
> Change-Id: I6b6c4a15e5d83f7e2bdc6082972993df179a5d87
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3461563
> Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
Bug: 1297458
Change-Id: Iac0294116f1a9e762a3847bcb0738955bba957b2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3641403
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@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>
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>
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>
Use fallback cases when showing the script location in
`buildDetailsTextForTraceEvent`.
Currently, we use the UILocation if existent (which is only
the case, if we have already parsed the `scriptId` of the Timeline
Event. If this has not been the case, it fell back to using
either the top frame, or nothing).
This CL changes this code to always use the fallback, instead
of trying to resolve the location:
1. This is both flaky on the tests (if crbug.com/1318635 is fixed
with https://crrev.com/c/3613395), and can be observed by the
developer as it is time dependent.
2. As is, there has been a backend bug (crbug.com/1318635) which
never sent the correct `scriptId` (int instead of string) for
stack traces anyway, so we used the fallback for that case, and
that is reflected on many layout tests as well.
3. Normally we try to use the live location using the script, but this
particular code produces not a link but a text, and is only used
for WebSocketDestroy events and the layout test infrastructure.
4. Setting it to default to the information we have, is deterministic.
Bug: 1318635
Change-Id: I5078d18d92d8b60d8c8d4253efe07f7527bb3c19
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3613875
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
At long last, we can remove the old unused fields now that no
deprecation messages are untranslated.
This CL is part of a series:
(1) Remove legacy info
(2) Translate issue title
(3) Translate demo Issue {CHROMIUM}
(4) Translate demo Issue {DEVTOOLS}
(5) Document new deprecation process
(6) Add milestone and status links
(7) Document milestone and status links
(8) Migrate DeprecationInfo::WithDetails {CHROMIUM}
(9) Roll deps
(10) Migrate DeprecationInfo::WithDetails {DEVTOOLS}
(11) Document changes in development process
(12) Migrate DeprecationInfo::* {CHROMIUM}
(13) Roll deps
(14) Migrate DeprecationInfo::* {DEVTOOLS}
(15) Cleanup Deprecations {CHROMIUM}
(16) Cleanup Deprecations {DEVTOOLS}
(17) Final documentation tweaks
DISABLE_THIRD_PARTY_CHECK=Fields are being removed, so we have to touch non-gen code
Bug: 1264960
Change-Id: If5a286a50cafc073ff99f5e0d8f3d38d5e8ba83a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3613607
Auto-Submit: Ari Chivukula <arichiv@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Commit-Queue: Ari Chivukula <arichiv@chromium.org>
When DevTools is intercepting and overriding the response to a request,
this response should have a response status of 200 (and not the response
status of the original response).
If body, headers and a redirect response code are sent to the backend
via `Fetch.fulfillRequest`, the response code will take precedence and
the response will be redirected instead of overridden.
Fixed: 1320400
Change-Id: Ib306369c67471f871425d2a1bbafe80cbb881d1f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3610172
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Simon Zünd