It is possible for TypeScript to import a file that is not included in
the corresponding devtools_entrypoint as a dependency. In many cases
this would likely cause the build to fail, but it's also possible that a
dependency might have been provided as a dep of another entrypoint.
Given that ninja parallelizes builds this results in a race condition
where on some builds the dependency that wasn't declared is there, and
on some builds it is not. This is further complicated if build artifacts
from previous builds are kept around.
This CL introduces a script that can be run manually that cross
references the files that GN knows about, and the files that TypeScript
expects to be able to import. Any files expected by the TypeScript
compiler that are not declared in the BUILD.gn (even indirectly as a
dep of a dep etc) will be flagged.
Change-Id: Ieb95600f11bfc20e0e71d8792a7f344b13a0fb8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2316063
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Inconsistent URL escaping was breaking snippets, which by default
have characters (space and #) which need to be escaped.
As a general rule, anything called 'url' or 'path' is now url-encoded,
and anything called 'name' or 'platformPath' is not.
Bug: 1094436
Change-Id: I7a26e9f2bfa676d0cc1b4731ea939ebc12222a25
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2266998
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Up until now we used getPossibleBreakpoints() in order to find the
breakable location, just for setBreakpoint to set a breakpoint
on the first returned location. Using setBreakpoint() directly
is more intuitive and straight-forward, and for our use case
it should result in the same breakpoint setting behavior.
Bug: chromium:1105172
Change-Id: Id9460dcddb714fafa32a4620116e29c62c03c301
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2306150
Auto-Submit: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
This CL creates a new CSS grid setting histogram to replace the previous
one, which was firing multiple times per setting change. Previously,
the histogram could fire once per target on the debug target page
when a setting changed.
This new histogram fires once on devtools launch, allowing us to
gain insight on user's settings preferences while also filtering
out several events from users quickly trying different settings
before settling on a prefered option
Backend CL: https://crrev.com/c/2304166
Bug: 1106888
Change-Id: I929befb8997ac0908e6c9aa90af509582b77ae49
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308256
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Shane Clifford <shanejc@microsoft.com>
Commit-Queue: Brandon Goddard <brgoddar@microsoft.com>
Because the border declaration was missing a defined colour it was not
inverted correctly in dark mode, meaning the border would be black which
is not easily spotted when in dark mode. To fix this I picked out the colour that was being used in light mode and explicitly defined it.
By declaring a specific black colour, it is then inverted into white in
dark mode and it's much clearer as the screenshots below show (no light mode included as this change is a no-op in light mode).
Before, dark mode (note the barely visible black border around the
margin): https://imgur.com/OuaagvW
After, dark mode: https://imgur.com/ecntqHp
Fixed: 1106683
Change-Id: I2a834d23f964efaa6757636460b8b5136bfdfb23
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308548
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
A missing check in json parsing caused loading of some of the standard
devices to fail, which leads to the bug: after user selects additional
devices, the device list does not appear to persisted - they persisted
but the reading failed, the "show" flag became Default, causing no show.
Tests to be added later.
Bug: 1107564
Change-Id: Idea0927ad108e2467f667329df8a70040696f9df
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2310811
Commit-Queue: Songtao Xia <soxia@microsoft.com>
Reviewed-by: Brandon Goddard <brgoddar@microsoft.com>
The internal ninja copy action is, for Linux and Mac, the creation of a
hardlink. In the case of an is_debug = false build, we copy the
devtools_entrypoint file with ninja to the gen folder. However, should
the file then change in the gen folder, those changes will be reflected
back in the original source file since the two are hardlinked. This does
happen when the JavaScript file moves to being managed by the TypeScript
compiler, for example, because tsc often changes blank lines and adds
sourcemap information to the file. If the gen folder is empty and no
hardlink exists prior to build, there are no issues. If, on the other
hand, the hardlink exists, and the TypeScript compiler runs, the file
written in the gen folder will update, and then so will its original
source.
The ways to resolve this reflection back to the source folder is either
by deleting the gen folder before rebuilding (where one anticipates
changes being reflected in source), or, instead of using the ninja copy,
using an action to call out to a script that will ensure that a new file
is created and not hardlinked.
This CL chooses the latter path.
Change-Id: Id2cc8acdc240eb73ac736ddaf6f1eabdd08f8359
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308534
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This patch simplifies the inspector overlay HTML and makes it more
consistent through minor changes like the following:
- drop redundant type="text/css" from <link rel="stylesheet">
- move <title> as early as possible (i.e. immediately after
<meta charset="utf-8">)
Some HTML files used in e2e tests had the same patterns and were changed
accordingly.
Change-Id: Ib18657f6c919186e8d264ae1542427a61eb4c823
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308537
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
When refreshing the page with DevTools opened, when refreshing
DevTools or when navigating back to a previously opened page, the frame
tree in the application panel should pre-select the element which was
last selected on the previous visit.
This works by comparing itemURLs of the tree elements with previously
persisted itemURLs. In the previous implementation any match between
those 2 arrays was considered a match. This could lead to the
selection jumping around on page refresh because there were multiple
matches. With this CL a match needs to start at the root node and
progresses along parent-child relationships.
Bug: https://crbug.com/1101262
Change-Id: Ica7275be6aaf13df5de1e800e9fbabf1449ec8bd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2300111
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
This ports the auto-stepping logic that was already available with the
DWARF prototype to the `wasmDWARFDebugging` experiment. The condition
here is as follows:
If we break on a raw location for which we have a reverse mapping
to a UI location, then we check whether any of the raw locations
to which the UI location maps is exactly the same as the break
location.
This seems to yield the expected behavior, but comes at a quite
significant cost (transfering all the stack frames and scope chains to
the DevTools front-end just to decide that we don't want to break here),
so eventually we want to find a better and more efficient way to do
this.
Bug: 1105765, 1083146
Also-By: pfaffe@chromium.org
Change-Id: Idc4a4f57f352322769557609dde7fe2aa26a7ce2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2300115
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
This CL extends the existing extension API to support debugger language
plugins hosted inside chrome extensions. The patch adds a new
experimental interface to allow extensions to egister a language plugin,
which then gets called by the debugger to provide debug information.
Drive-By: Drop the experimental out-of-process language plugin made
obsolete by the language extensions.
Bug: chromium:1083146
Change-Id: Icbf755e5761f6b7a5df6406a725e38eba965683e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2245146
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
If we use a local timeout rather than letting this timeout the whole
mocha process, we get a way better error message which includes
info about the selector/function/whatever we care about, and the
step name. Without this we just get the test file name and nothing
else.
Change-Id: Ia2882fb123a6f2b582c0dd19f3f01135b496161a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2292276
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Simon Zünd
