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>
Remove the global WeakMaps from the DefaultScriptMapping and replace
them with per-instance Maps that are properly updated. Since there's
still the static `scriptForUISourceCode()` method around, we use the
same temporary workaround as in the `CompilerScriptMapping` of having
a global Set of all the instances meanwhile.
Also most importantly the UISourceCode to Script mapping is always
a 1:1 reverse mapping of the Script to UISourceCode mapping (while
our implementation was maintaining a Set of scripts for each of the
UISourceCodes in the global mapping).
With this change it's not only more efficient (avoiding the potentially
huge WeakMaps and favoring much cheaper - from a GC perspective - Maps),
but also easier to reason about the behavior of this mapping.
Bug: chromium:1379221
Change-Id: I5ed2493d2a001f315d690b7883a1d68ce369b1e5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4161377
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@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>
If a user adds a breakpoint in an inline script before the embedding
document is loaded, the breakpoint will not be persisted under the
correct URL, so the breakpoint does not persist across reloads.
This patch makes sure that we use the emedding document's URL for
breakpoints in inline scripts. This unfortunately requires some
tricky translation between the inline script's and the embedding
document's line-column coordinates.
Bug: chromium:1355758
Change-Id: I903d3dd5656fdb67da4ecf25c89bbf4eb7983b1c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4061712
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
If the debugger stops in an inline script without source URL before the
embedding HTML arrives, the stopping position in the source view is off.
This adjusts the source positions to account for the fact that for
scripts without sourceURL, v8 provides source positions in embedder
coordinates, but the devtools maps to the embedded script locations.
Bug: chromium:1325457
Change-Id: Ia56bec7fe1c3db678c4167a0ef01d4fffbfccada
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4038144
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
This is a reland of commit 1b596f3b4b.
Changes:
1. Gated behind an experiment
2. Removed changes that are currently not used since it's gated
(i.e. test changes)
Original change's description:
> Enable synchronization on instrumentation breakpoints
>
> This CL introduces the synchronization point for setting
> breakpoints on new scripts using instrumentation breakpoints.
>
> Instrumentation breakpoints will trigger at the first statement
> of a newly run script. Afterwards we wait for all resources
> that we need to set a breakpoint (if one is cached for that
> particular script), set it, and resume.
>
> Note: this will not correctly synchronize the case where we
> just opened DevTools or just created a new target, as at this
> point some scripts might have started running. For this, we
> need to synchronize the Debugger.enable call, which is something
> that is left to take care of.
>
> Bug: chromium:1229541, chromium:1133307, chromium:1300509
> Change-Id: I44e9b053a7cf64cc1f477a68ce9389cd92a1d05d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3470237
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Bug: chromium:1229541, chromium:1133307, chromium:1300509
Change-Id: I19553ddac9530fa3ccac6b245a3dd89da88c6d51
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3542248
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
This reverts commit 1b596f3b4b.
Reason for revert: closed the tree, more blink tests to adapt
Original change's description:
> Enable synchronization on instrumentation breakpoints
>
> This CL introduces the synchronization point for setting
> breakpoints on new scripts using instrumentation breakpoints.
>
> Instrumentation breakpoints will trigger at the first statement
> of a newly run script. Afterwards we wait for all resources
> that we need to set a breakpoint (if one is cached for that
> particular script), set it, and resume.
>
> Note: this will not correctly synchronize the case where we
> just opened DevTools or just created a new target, as at this
> point some scripts might have started running. For this, we
> need to synchronize the Debugger.enable call, which is something
> that is left to take care of.
>
> Bug: chromium:1229541, chromium:1133307, chromium:1300509
> Change-Id: I44e9b053a7cf64cc1f477a68ce9389cd92a1d05d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3470237
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Bug: chromium:1229541, chromium:1133307, chromium:1300509
Change-Id: I9eccdf065820854746ec7ad4643362859c9960e4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3506653
Auto-Submit: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Johan Bay <jobay@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Owners-Override: Kim-Anh Tran <kimanh@chromium.org>
This CL introduces the synchronization point for setting
breakpoints on new scripts using instrumentation breakpoints.
Instrumentation breakpoints will trigger at the first statement
of a newly run script. Afterwards we wait for all resources
that we need to set a breakpoint (if one is cached for that
particular script), set it, and resume.
Note: this will not correctly synchronize the case where we
just opened DevTools or just created a new target, as at this
point some scripts might have started running. For this, we
need to synchronize the Debugger.enable call, which is something
that is left to take care of.
Bug: chromium:1229541, chromium:1133307, chromium:1300509
Change-Id: I44e9b053a7cf64cc1f477a68ce9389cd92a1d05d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3470237
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@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