ui/Tooltip.js overrides the HTMLElement prototype to override the
title property. Rather than using this property, we shoul be
calling Tooltip.install directly. This makes sure that new
components are not relying on the behavior of the legacy
prototype patching.
These usages have been manually audited using the following regexes:
Search: ([\S]+)\.title = ([^;]+);
Replace: UI.Tooltip.Tooltip.install($1, $2);
Note that there are classes in DevTools that also have a title
property. Most notably `TreeElement`. We should not be replacing
these, as they do not inherit from HTMLElement. Luckily, we are
running TypeScript to make sure we don't call `Tooltip.install`
with a non-HTMLElement.
A follow-up CL will clean up the getters.
R=jacktfranklin@chromium.org
Bug: 1150762
No-presubmit: True
Change-Id: I5928e75c70293531849e0576f4fb2a2a8b3e02d2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2555060
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@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>
By using the script in crrev.com/c/devtools/devtools-frontend/+/1942289
we can prune all globals that are not actually global. Most of these are
internal private variables that are now module-scoped. Some variables
were also completely unused, which ESLint nicely reported.
Change-Id: I43689ac7544ad1239acc7d0eeec4dcd563d7fea9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1942290
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
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
Previously, there was a property order mismatch between the DevTools
Console Preview and the expanded view. For example:
input> ({ c: 1, b: 1, a: 1 })
preview> {c: 1, b: 1, a: 1}
expanded> {a: 1, b: 1, c: 1, __proto__: Object}
This patch removes the confusing mismatch as follows:
input> ({ c: 1, b: 1, a: 1 })
preview> {c: 1, b: 1, a: 1}
expanded> {c: 1, b: 1, a: 1, __proto__: Object}
The core change happens in ObjectPropertiesSection.js. The test
expectations are updated accordingly (note that for each test, only
the order in which properties/values are printed changes). The patch
also includes a drive-by change across files unifying the way U+00A0
is escaped in string literals.
Screenshot: https://goo.gle/devtools-property-order-mismatch
BUG=989514
Change-Id: I102afcbd107100a52e0932401429a3fa8db99eaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1806457
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#697200}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: dcc366c27c78ce40ca6f05ac8000528896b4549a
Introduces JavaScriptREPL, a utility that includes
- Logic used by EagerEval for building side-effect-free previews
- Console prompt's preprocessing logic
(object literal wrapping and top level await)
Bug: 849875
Change-Id: Ie8146435fced9ebf440b43c225d25ef145416247
Reviewed-on: https://chromium-review.googlesource.com/1145911
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#577341}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f8ffab5d79243cb7de978d17669e8decdb9141df
Tim van der Lippe
