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>
When a binding is created, the NetworkPersistenceManager will
make sure to synchronize the already fetched content of a network
resource with its override version. As a result, the script
source content is re-set, and all breakpoints that were
previously set on the network resource are refreshed
(i.e. removed and reset) in order to reflect the up-to-date state.
This update of breakpoints even happens if the two sources
do not differ. In this case, we unnecessarily remove and reset
breakpoints.
With instrumentation breakpoints, this logic would sometimes
remove the breakpoints that we've already set, just to reset
it at the exact same position.
In order to avoid removing breakpoints that we've already
correctly set, this CL makes sure to only update the
source code if the new source code differs from the old one.
This also adds a test for network persistence using the new
Mock Connection Backend.
Bug: 1396298, 1395337
Change-Id: I057cd6a49cec45ad88c837b602bcace9cd3a7968
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4154498
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
The new method is used to get a uiSourceCode for a given script. This
will be used for instrumentation pauses, when we await a uiSourceCode
for setting a breakpoint.
This CL also adds instrumentation breakpoint tests for inline
scripts (with and without the html uiSourceCode being available),
and for regular scripts; with the latter one replacing an old
test using the old infrastructure. These tests all make use of the
uiSourceCodeForScript method.
Bug: 1396298, 1395337
Change-Id: Ic699a39cc414bd831d2d34afdd848317d32eae90
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4111047
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@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 CL adds the eslint-plugin-jsdoc plugin and enables just one rule,
`jsdoc/check-alignment`, which ensures that all the lines in a comment
are correctly aligned. For example:
```
/**
* foo
* bar
*/
```
Would fail the check and be corrected to:
```
/**
* foo
* bar
*/
```
DISABLE_THIRD_PARTY_CHECK=deliberate install + use of
eslint-plugin-jsdoc node_module
Bug: none
Change-Id: I969983cd550653654a334ede3409b8c850467245
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4110906
Commit-Queue: Andres Olivares <andoli@chromium.org>
Reviewed-by: Andres Olivares <andoli@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Currently, there is a subtle difference in relative path resolution for
source URLs in resource script mapping and in the source map manager: If
the base URL (the URL of the containing frame) cannot be used to make
the source URL absolute (for example, if the base URL is a data URL),
resource script mapping would interpret the URL as one without a domain,
but source map manager's resolution would fail and the source map would
not be used.
With this patch, we change the source URL resolution for source maps
to be the same as for resource script mapping - if the URL cannot be
completed to an absolute path, we just keep the URL as is.
Bug: chromium:1383416
Change-Id: If2f736535b0a09603f697e4be69864ca06d6ae24
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4020558
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
The `//# sourceURL=something` annotations aren't constraint in any way,
and the `something` can literally be any arbitrary string. The sourcemap
spec however states that the sourceURL should be resolved relative to
the parent documents base URL, which we already do for source-mapped
files, but so far hadn't done for files that only contain a sourceURL
annotation without also containing a sourceMappingURL annotation.
With this change, the ResourceScriptMapping now does that job for
standalone scripts as well, similar to what the CompilerScriptMapping
does (indirectly via the SourceMapManager) for source-mapped files.
Before: https://imgur.com/5WbWyjU.png
After: https://imgur.com/S2e89Vj.png
Fixed: chromium:1183990
Change-Id: Ibae159867233b52172d187475544d889e491239b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3657449
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
This CL utilizes the new status enum to decide whether to display an
error or update the script's content.
Keep in mind that until now we didn't actually show the console
message for a failed live edit. That is because all errors were
reported with an "exceptionDetails" object even for non compile
errors.
So already this CL is a great improvement for error reporting
as non-compile live edit failures get finally printed to the
console.
R=jarin@chromium.org, kimanh@chromium.org
Bug: 1334484
Change-Id: I27f484fa510bd2a2f9c43d250f7e9d1fdb581a3e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3706923
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
This CL changes Script#editSource to return the result via its Promise
instead of a dedicated callback. This CL also removes the indirection
via the DebuggerModel, which was a bit weird: We had the Script object
already in ResourceMapping, but would only use the scriptId and then
the DebuggerModel would resolve the script object again.
A follow-up CL will change the `error` string to use an enum that
incorporates the new LiveEdit response status as well to improve
error reporting.
R=kimanh@chromium.org
Bug: 1334484
Change-Id: I654fb94a1969e2b56b2e222d6e1c8f495d53b9bb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3711560
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
For wasm debugging it's possible that debug info is incomplete on a per-callframe granularity. When debug info is incomplete we currently show a warning banner in the call stack sidebar pane and a little warning icon next to the affected callframes. It's too easy to overlook this. With this CL we're introducing a prominently red error infobar directly in the editor when an incomplete callframe is selected.
Bug: 1331281
Screenshot: See crbug.
Change-Id: Id804e087a0f04d8daa9169a77e0e78eb8556e6c9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3610169
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Peter Müller <petermueller@chromium.org>
Following up on https://crrev.com/c/3069289 the back-end reports
positions (raw locations) for inline scripts with `//# sourceURL`
annotations relative to the start of the <script> tag content, rather
than relative to the surrounding document.
The DevTools front-end however was still trying to make up for the
wrong positions reported by the back-end, leading to negative line
numbers being reported and sometimes jumping to the wrong line when
using inline scripts with `//# sourceURL` annotations.
This change removes the hacks from the front-end and simply uses the
positions from the back-end, which are now correct.
Fixed: chromium:1270227
Bug: chromium:578269, chromium:1183990
Change-Id: I65a59f64f42230179f56218518e727116329ad5d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3291151
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Benedikt Meurer
