Currently the devtools-frontend doesn't really distinguish between
UI locations that point to the first column (represented as column
number 0) and UI locations that refer to the whole line, and somehow
we managed to get away with this mixed state. But for the language
plugins to really provide a consistent stepping / breakpoint experience
we need to preserve the information of whether a location refers to the
whole line or to the first column.
The communication to the language plugin continues to pass numbers
for backwards compatibility, using `-1` to state the absence of
column information (i.e. indicating that the location refers to the
line as a whole).
Also-By: pfaffe@chromium.org
Bug: chromium:1153123, chromium:1055327
Change-Id: I030da16e34ac02c259bfd9539e50b77ca18347db
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562350
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Previously when something fails during disassembly generation, we'd
silently swallow the promise rejection and abort early, leaving the
UI in a weird state (the "Loading..." bar would never disappear and
the source tab remain empty forever).
Bug: chromium:1136484, chromium:1137335
Change-Id: I7fa03fcdead8be4c027d1118aafefcd5ee82eb2c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2463355
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
This rule disallows assigning a value in a return statement.
It also works in one-liner arrow functions.
For instance, a => a = 2 will trigger a warning.
This is to avoid cases where you actually meant to compare a to 2, not
assign the value 2 (maybe you wanted to return a boolean in a filter
callback).
These sorts of issues can easily pass review and cause weird problems
that are hard to track down later.
The rule is enabled in this CL, and all warnings are fixed with this CL.
More info about the rule: https://eslint.org/docs/rules/no-return-assign
Bug: 1093379
Change-Id: I38b98ea59ecaedc83a7f69073b17980808f9a3bf
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2242761
Reviewed-by: Patrick Brosset <patrick.brosset@microsoft.com>
Reviewed-by: Jose Leal <joselea@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Patrick Brosset <patrick.brosset@microsoft.com>
Change the wasmparser worker to emit progress events for the name
section decoding, the actual disassembly generation and the joining
of the lines. This way the progress bar in the front-end becomes
more useful for bigger wasm modules, where it's otherwise unclear
to the developer whether DevTools is still doing something or got
stuck somewhere due to a bug.
Fixed: chromium:1090262
Bug: chromium:1043030, chromium:10714320
Change-Id: I38403b17eb27da554855e9cc40e2d6d383df5e4d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2230535
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This refactors the editor location done in the `UISourceCodeFrame`
via the `Transformer` in the following ways to make it more robust,
preparing for hooking up the WebAssembly disassembly here as well:
1. Remove the duplicate `Transformer` typedef.
2. Turn the `Transformer` typedef into a proper interface and have
`SourceFrameImpl` implement it.
3. Rename the `Transformer` methods to make sense and adjust the
return type to an object with meaningful field names, rather than
an ad-hoc array with two elements.
Bug: chromium:1056632
Change-Id: I3d08b54dab3a04a8595e3a498127f9f91d686694
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2220091
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
We prefer single quotes by default, but still want to allow double
quotes in cases where that helps avoid quote-escaping, and also want
to allow template literals in cases where string interpolation is
used. For example:
const a = 'xxx'; // ok
const b = "xxx"; // not ok, should use single quotes
const c = "xxx'xxx"; // ok, double quotes avoid an escape sequence
const d = `xxx`; // not ok, frivolous use of template literal
const e = `xxx ${42}`; // ok
Per https://github.com/eslint/eslint/issues/12976, setting
the `allowTemplateLiterals` option for the `quotes` lint rule to
`false` gives us the desired behavior.
Note that the above lint rules are auto-fixed when running the linter;
there should be no need to manually make any changes to appease the
linter.
Per review feedback, this patch also removes the following escape
sequences for printable non-ASCII symbols:
- U+00D7 → ×
- U+2026 → …
- U+2019 → ’
Chromium CL temporarily updating test expectations:
https://chromium-review.googlesource.com/c/chromium/src/+/2083147
Cq-Depend: chromium:2083147
Bug: chromium:1057042
Change-Id: Id6bec3f96ca694d2fbc07dd8629fce305a58df8a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2082372
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Mathias Bynens <mathias@chromium.org>
The ScriptOriginPlugin uses source mapping to resolve a UISourceCode to
a script in order to display a toolbar item for that script. As source
mapping will be asyncified the UISourceCodeFrame needs to provide its
toolbar items in an async way.
Luckily, UI.SimpleView has both a async and non-async version for
sub-classes to provide toolbar items. This CL replaces all uses of
the non-async version with the async version and removes the
non-async version from the interface alltogether.
R=sigurds@chromium.org
Bug: chromium:1032016
Change-Id: Ifce141ccf17bbce3493cb5ffb16aa6874abfe413
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1981624
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
The source editor, when it cannot load a particular file, will simply
display a blank file instead. At the bottom, this is because the APIs
used to load the files do not have a way to propagate an error up to
the call site. Rather, the callback either is never called, or is
called with just an empty string.
This refactor changes the way the project system loads file contents
by replacing the callback model with a Promise-based model. However,
in this version, rather than propagating an error (handled via
catch), the error is exposed as a property on the object passed via
the the load functions. Although it might be preferable to use
async throw/catch, because there are ~4-5 layers of redirection
through the project system, the added complexity seems to not really
justify that work. I'm open to reconsidering this design, though.
Attempting to load a file via file:// which does not exist previously
produced no error because the DevToolsUIBindings handler would just
always resolve with no content and HTTP status 200. I had previously
addressed that bug in this changeset, but I've split it out to
https://chromium-review.googlesource.com/c/chromium/src/+/1847833 .
Sample "after" screenshot: https://imgur.com/a/tlm90sg
Bug: 961940
Bug: 941035
Change-Id: If121611090e9c35eeb1de162b59f8a9f72f696d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1817677
Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
Reviewed-by: Jeff Fisher <jeffish@microsoft.com>
Commit-Queue: Lorne Mitchell <lomitch@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#705438}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 61ec2a233d9a7bf4bb4b3e610de6fc233ae0d46e
The Chromium/Google style guides does not enforce curly braces for
single-line if-statements, but does strongly recommend doing so. Adding
braces will improve code readability, by visually separating code
blocks. This will also prevent issues where accidental additions are
pushed to the "else"-clause instead of in the if-block.
This CL also updates the presubmit `eslint` to run the fix with the
correct configuration. It will now fix all issues it can fix.
Change-Id: I4b616f21a99393f168dec743c0bcbdc7f5db04a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1821526
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jeff Fisher <jeffish@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#701070}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7e0bdbe2d7f9fc2386bfaefda3cc29c66ccc18f9
We currently use the mime-type determine into which mode to put
CodeMirror. For the most part this is fine, save for JSX/TSX projects
where the files are saved with .js/.ts files suffixes. Typically this
causes the non-x mime-type to be chosen, which in turn puts CodeMirror
into the wrong mode. Since JSX/TSX are supersets of the non-x versions
this CL simply pushes the mode over to the respective superset.
Bug: 659515
Change-Id: I186d976a6a1ac991a296f92a22c8a0b3e83743c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1800748
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jeff Fisher <jeffish@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#697180}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b3c794969b499b588fea13020080ab47f86fc576
The new compiler caught a lot of pre-existing issues in the codebase.
Sadly, the old compiler version was not smart enough to understand the
new changes. Therefore, the changes have be included in the same CL as
the compiler update.
Most of the changes are related to better handling of prototype and
class inheritance, as well as handling of null/undefined tracking.
Change-Id: I3941a3a240a4d09c4945e1e20d2521090ef837c9
Bug: 991710
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1762081
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@google.com>
Auto-Submit: Tim van der Lippe <tvanderlippe@google.com>
Cr-Original-Commit-Position: refs/heads/master@{#696761}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ca93474213278e32e36d6ace1474c56884030757
Tab titles in the devtools are not localizable, this PR makes the title function to actually use l10n tagged templates and fixes the following comment on the code:
third_party\blink\renderer\devtools\front_end\Runtime.js
// FIXME: should be Common.UIString() but runtime is not l10n aware yet.
Change-Id: I4a651e2f1b4ef0e0e6d07b54d52e44c17aeda057
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1554648
Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#652717}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 47fe01c857b5aff69d66e36e994bb7796748907b
I extracted out some improvements to inplace pretty print in
SourceFrame from my sources auto pretty print patch.
* Line numbers become blue when pretty print is active
* Selection is properly scrolled into view when pretty print is toggled
Change-Id: Ib1cf8f0a15b8495594ecf121cef8786d8cfd0f16
Reviewed-on: https://chromium-review.googlesource.com/1044878
Commit-Queue: Joel Einbinder <einbinder@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#556318}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d893a023c6a2ad473795fc680170c2a018eedab3
onTextEditorContentSet is a legacy method from when SourceFrame had
many subclasses. Overriding setContent instead is simpler and makes
for a cleaner plugin story around dispose/ensure plugins.
As a drive-by, the currentSearchResultIndex getter was removed.
Change-Id: I7f467da9297288b9f654eaf1cdd73b8be281cbaa
Reviewed-on: https://chromium-review.googlesource.com/1020812
Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org>
Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#553320}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1e760fbec07f32c51baadf82e967d2e21ae3650c
This gets the highlighter type from the network UISourceCode, if it
exists. For overrides files with no extension, they will stay colorful
as long as they are bound.
Change-Id: I5f1ff41f54eabb7a7f1abf1aa27b19629529fbfd
Reviewed-on: https://chromium-review.googlesource.com/1003875
Commit-Queue: Joel Einbinder <einbinder@chromium.org>
Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#549683}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e832b8e15e96305ca27ce44aaa95e910ffc42ace
Philip Pfaffe
