This introduces a new uiLocationRangeToRawLocationRanges() method to the mapping layer which will be used by possibleBreakpoints() in the
BreakpointManager in the future to determine the set of raw location
ranges within which to ask V8 for breakable locations.
The new uiLocationRangeToLocationRanges() takes into account even
special cases like holes that can result from funny source maps, and in
the future should also be useful to compute the skip ranges for the
auto-stepping logic.
For the SourceFormatter ScriptMapping we kept the assumption that the
ranges must be contiguous even though they don't necessarily are (for
formatted documents with inline scripts), but the whole SourceFormatter
functionality is basically deprecated at this point and will soon be
removed (in-place pretty printing was enabled by default with M-111
already).
Bug: chromium:1409365
Change-Id: I3ec7db0ad32272a0af96c2c06f8506d4886bbe9e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4196922
Reviewed-by: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
These classes were basically 1:1 wrappers around the protocol types, and
there's no reason to have them as separate classes as well. It just
makes things unnecessarily challenging to understand (because it isn't
immediately obvious what the difference is) and harder to reason about.
Also rename the RawLocationRange to LocationRange now and use that type
in the appropriate places.
Bug: chromium:1409365
Change-Id: I9ce5a3c272c5592a4ee9322fcdbf07832bae7063
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4196914
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
The fact that sourcemaps know about initiators presents a layering
violation and hiding the logic to request source contents within
the `SourceMap` class makes it difficult to tackle the problem of
dealing with resources that fail to load.
Drive-by-fix: Also remove i18n from the source map error messages. We
currently translate only a few of the errors, which leads to a quite
inconsistent experience; it's better to not translate them at all for
now (especially since we have no control over the error text that comes
out of JSON.parse() for example).
Bug: chromium:1262113
Change-Id: I45df23b99e2fc3d42a47e3999df4ab8d75b54541
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4161383
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This introduces a new `getMappedLines()` method on the debugger
workspace binding, which consults the appropriate methods in the
debugger plugins, as well as the mappings, to compute the set of
lines that map to scripts (for the breakpoint line gutter).
With this CL we now properly indicate the script lines within
HTML documents, and we also remove one of the two last remaining
static methods on the `CompilerScriptMapping`.
Note that even with this refactoring, we are still lying about
breakable lines in the breakpoint gutter, since just because a
line is mapped to a script doesn't necessarily mean that it's
possible to set a breakpoint on this line. Fixing this will need
a combination of the mapped lines information with information
about possible breakpoints from V8.
Bug: chromium:1185770
Change-Id: Ie8481df799d3986a24caea5117a884c2a1cd0433
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4161371
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Previously `ProjectStore.uiSourceCodes()` was implemented to return an
internal array of `UISourceCode`s that was mutated as sources got added
and removed from the project. This led to subtle bugs when removing
sources from a project by just iterating over this array, where because
of the funny compaction logic the iterator would skip over items and
miss them.
The internal implementation of this is also unnecessary complex by using
both a Map and an Array. We can drastically simplify this by simply only
using the Map and having `ProjectStore.uiSourceCodes()` return an
iterable that adheres to the `Map#values()` rules, and in particular is
safe to use while removing items from the store.
Bug: chromium:1406449
Change-Id: I751126906357c5e27f08c3bf7a6e278094d801d1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4154491
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This simplifies the implementation and usage of the
ContentProviderBasedProject, such that:
1. There's only a single internal mapping from UISourceCode to
content provider, mime type, and metadata, instead of having
two separate mappings.
2. Due to the first simplification we no longer need to have the
dedicated removeFile() method, which basically just calls through to
removeUISourceCode(), but additionally also maintained the separate
content provider mapping (this was a bit of a bug farm and I hit this
multiple times during the past 3 years).
3. Inside removeUISourceCode() there's no need to perform the
UISourceCode lookup two times.
Bug: none
Change-Id: I4560893cf0729a153ee4a7d7e4de904b8619898f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4154490
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This basically adds proper support for "hot module replacement" to
the `CompilerScriptMapping` by resolving conflicts between source maps
within the same target using the following strategy:
1. If two source maps from different scripts reference the same authored
file, and neither of the source maps provides content for the file
and agree on the ignore-list hint, we consider this to be the same
authored file.
2. If two source maps from different scripts reference the same authored
file, and both source maps carry the same `sourcesContent` for the
file and agree on the ignore-list hint, we consider this to be the
same authored file.
3. In all other cases we assume that there is a conflict, and we further
assume that the intention here is to replace the authored file with a
newer version (via "hot module replacement"). We therefore unlink
the previous `UISourceCode` for the authored file and mark all
mappings from earlier source maps to this `UISourceCode` as stale,
meaning that future attempts to resolve the mapped locations from the
associated scripts will not find a `UISourceCode` coming from the
`CompilerScriptMapping` (but will fall back to the default mappings).
The "stale source map" case is especially interesting, since we need to
ensure that not only UI to raw location lookups will ignore stale
UISourceCodes, but also when mapping raw to UI locations, we need to
double check that the UISourceCode we find is still active for the
source map associated with the script.
Drive-by-fix: Add documentation and more test cases for this
functionality.
Doc: http://go/devtools-source-identities
Doc: http://go/chrome-devtools:web-starter-kit-2022-investigation
Fixed: chromium:1403432, chromium:1404703
Bug: chromium:1403362, chromium:1069378
Change-Id: Ic54043e4c6d6ca703bdcec6d300e282518503c41
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4128466
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
The fix in https://crrev.com/c/2742490 put the logic for updating the
live locations of inline scripts into the wrong place, and also did not
perform the live location update for inline styles. It was the wrong
place because the CompilerScriptMapping is concerned with sourcemap
related UISourceCodes, whereas the ResourceMapping is responsible for
documents (with inline scripts and styles). The previous fix worked by
chance due to a specific order of events for scripts.
This patch puts the logic into the correct spot, and extends it to also
update the locations for inline styles once the document is loaded.
Bug: chromium:1184162, chromium:1403432
Change-Id: I659bc8899b8b2cec03f9fd225648c6d305194694
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4127779
Reviewed-by: Andres Olivares <andoli@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
The SourceMapManager was trying to cache sourcemaps by their "source map
id", which was basically the concatenation of sourceURL (of the client)
and sourceMappingURL (of the sourcemap). This caching is unsound by
itself, since the content of both the client and the sourcemap can
change without changing their URLs. So there was already quite a bit of
ducktape on top (in DebuggerModel) to forcibly detach sourcemaps when
there it would detect a clash (based on execution ID, sourceURL and
sourceMappingURL). But even this ducktape still left plenty of ways open
in which a stale sourcemap could be fetched from this cache (one of the
easy ways to reproduce is demonstrated in https://crbug.com/1403362).
One alternative how to go about this would be to also include the client
content hash into the mix (i.e. the script hash for JavaScript). But
right now we don't have the hash available for the stylesheet contents,
and even if we did, it wouldn't fix the fundmental problem either, since
the sourcemap (and sources) can change while still producing the exact
same bundle in case of both JavaScript and CSS.
So the appropriate solution is to remove this caching layer and instead
rely on Chrome's caching for sourcemaps (parsing sourcemaps is fairly
cheap on common developer hardware, so that's a complete non-issue).
This CL thus drastically simplifies the SourceMapManager and adds a
significant chunk of test coverage for the interesting behaviors.
Specifically this means now that there's a 1:1 mapping between
sourcemaps and clients, rather than this strange 1:N mapping that we
used to have before (which would almost never trigger except when it
shouldn't).
Drive-by-fix: Remove i18n from the SourceMapManager, as this is a
layering violation and we generally don't localize internal error
messages (like the warn() call in SourceMap.ts is not localized either).
Fixed: chromium:508270, chromium:1403362
Change-Id: I2c7d29635ba085c433bdb3cc691f720e9c158808
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4120261
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
This CL affects V8 blackboxing on the backend, and the presentation of call frames in the Call Stack sidebar pane on the frontend.
The situations in which ignore-listing will affect the UI on the frontend will be consolidated in separate CLs.
Bug: 1323199
Change-Id: I4afe69ca9eaa0d6b15bf365fb57baa5acb741fa6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3762474
Commit-Queue: Victor Porof <victorporof@chromium.org>
Reviewed-by: Eric Leese <leese@chromium.org>
This reverts commit a09263601b.
This change did not cause the original breakage, so we are relanding
the original CL as is.
Original change's description:
> Improve stepping with source maps
>
> This aligns stepping through source maps with stepping through
> Wasm+Dwarf: when stepping from a location, we lookup the corresponding
> source location and then make sure we skip all the raw/compiled
> locations that correspond to that source location.
>
> To implement the skipping, we reuse the skipList mechanism that is
> already used for stepping through Wasm+Dwarf.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3093161
Bug: crbug.com/1232347
Change-Id: Ibe83e035aea73f070949902051dd8f100dde6f32
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3172834
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
This aligns stepping through source maps with stepping through
Wasm+Dwarf: when stepping from a location, we lookup the corresponding
source location and then make sure we skip all the raw/compiled
locations that correspond to that source location.
To implement the skipping, we reuse the skipList mechanism that is
already used for stepping through Wasm+Dwarf.
Bug: crbug.com/1232347
Change-Id: Ib19695b2078256282189df5b10d9165633849799
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3093161
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Benedikt Meurer