With this CL, we remove the `.chrome-select` CSS class and the two
different ways of styling a `<select>` element (excluding the completely
custom thing in the Recorder panel), and only have one set of styles
that we use consistently for all `<select>` elements (modulo the one in
the Recorder panel b/c LitElement), independent of whether the
`<select>` is used in a toolbar or elsewhere.
That means we can now simply put a `<select>` directly into a
`<devtools-toolbar>` and it will work as expected.
Drive-by-fix: Skip the test from crbug.com/383478771 completely now,
since even though the `<select>` in the Recorder panel is unaffected
by these changes, some surrounding (likely) timing changes now make that
test fail consistently, not only on Mac.
Bug: 383478771, 388445687
Change-Id: I01d7835d5858cac8863a7337a8e43a49b55820f2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6163607
Commit-Queue: Danil Somsikov <dsv@chromium.org>
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
This is the first step towards making it possible to use the `Toolbar`
component within lit-html templates. It turns the `UI.Toolbar.Toolbar`
class into an `HTMLElement` and removes its shadow DOM, using a light
DOM instead with global styles. This makes it possible to easily style
toolbars and their elements differently in different context, without
having to inject additional styles into the shadow DOM manually.
Bug: 388445687
Change-Id: I7a4e03a8c12978b7d9d9da79597b656409b3a9cb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6157257
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Danil Somsikov <dsv@chromium.org>
We have a mix of `type` and `interface` usage throughout our codebase,
that is sometimes difficult to follow and reason about. We should follow
the suggestion from the TypeScript PM and use `interface` consistently
where possible. This leads to better type display in errors and makes
our codebase easier to read (b/c consistency).
This CL adds the `@typescript-eslint/consistent-type-definitions`
ESLint rule to accomplish this.
Fixed: 387237537
Change-Id: Idb9e8275ddd8f633021d6cf1c933e2e55f980e45
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6152576
Auto-Submit: Nikolay Vitkov <nvitkov@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
With this CL when a user clicks on an annotation label in the timeline
we now will select the associated entry. This is a useful change because
when the event is small it can be hard to select, especially when zoomed
out. But the label is always going to be (relatively) large compared to
the event, so let's allow them to click the label.
Bug: 383120286
Fixed: 388224764
Change-Id: Ia58c2ffd8e075087480e651e31e0fea186039a54
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6148172
Reviewed-by: Alina Varkki <alinavarkki@chromium.org>
Commit-Queue: Alina Varkki <alinavarkki@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
This reverts commit af6c6337aa.
Reason for revert: The latest version of EsLint v9 does not work with the plugin added here, also the rule does more that just change shape objects from type to interface.
Original change's description:
> [eslint] Prefer TypeScript `interface` over type aliases.
>
> We have a mix of `type` and `interface` usage throughout our codebase,
> that is sometimes difficult to follow and reason about. We should follow
> the suggestion from the TypeScript PM and use `interface` consistently
> where possible. This leads to better type display in errors and makes
> our codebase easier to read (b/c consistency).
>
> This CL adds the `etc/prefer-interface` ESLint rule to accomplish this.
>
> Fixed: 387237537
> Change-Id: Idd6775094ba94b8397f626191788437f6b156dc6
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6135001
> Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
> Reviewed-by: Nikolay Vitkov <nvitkov@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Bug: 387237537
Change-Id: I6ecf18bfdaa4ad9efb17f0801def528035f9e703
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6140555
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Nikolay Vitkov <nvitkov@chromium.org>
We have a mix of `type` and `interface` usage throughout our codebase,
that is sometimes difficult to follow and reason about. We should follow
the suggestion from the TypeScript PM and use `interface` consistently
where possible. This leads to better type display in errors and makes
our codebase easier to read (b/c consistency).
This CL adds the `etc/prefer-interface` ESLint rule to accomplish this.
Fixed: 387237537
Change-Id: Idd6775094ba94b8397f626191788437f6b156dc6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6135001
Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
Reviewed-by: Nikolay Vitkov <nvitkov@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
`assert.ok` is an alias for `assert.isOk`, and similarly `assert.notOk`
is an alias for `assert.isNotOk`. For consistency with other assertions
such as `assert.isNull` and `assert.isNotNull`, we enforce the use of
the slightly longer form here as well.
Bug: 386335487
Change-Id: If845a5675a78598d01b30532985239f74f701db7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6120409
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Require the more descriptive `assert.isTrue`, `assert.isFalse`,
`assert.isNull`, `assert.isUndefined`, and friends instead, which also
produce a more meaningful error message than the generic
`assert.strictEqual`, `assert.deepEqual`, and friends.
Bug: 386335487
Change-Id: Ic58a07381196c358a43857b53364d74076e9c7e8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6113833
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
In our tests, we should stick to ideally just one way of asserting
array-like lengths, `assert.lengthOf`, and avoid any kind of
combinations `assert.equal`,`assert.strictEqual`, `assert.deepEqual`,
or `assert.deepStrictEqual`.
Bug: 386335487
Change-Id: I8f88e214acdae0c6e34dbb169c62ebc9a80317af
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6113832
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Previously we have been a bit sloppy with sometimes using one or the
other. In Chai both methods perform exactly the same comparison, but
the name `deepStrictEqual` can be a bit confusing to developers not
familiar with the Chai implementation, and particularly might leave
you wondering what exactly is *strict* about this method.
Fixed: 386330115
Change-Id: Idda55ee784b01cce650996ab3d56f76e220e6b2c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6110227
Commit-Queue: Samiya Caur <samiyac@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Samiya Caur <samiyac@chromium.org>
By checking that we only assign events to flows once given a flow
binding tuple (a token that allows us to match events to flows,
consisting of the event's ts, cat, pid and tid).
Perfetto's trace event format [1] only considers the first event that
matches a given binding before assigning an event to a flow. By being
consistent with this behavior we are able to skip subsequent events with
a matching binding and save quite some time on traces with many repeated
flow binding tuples.
To prevent further regressions, added a perf test case that consistently
fails on the previous state.
[1] https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview?tab=t.0#heading=h.4qqub5rv9ybk
Fixed: 382545507
Change-Id: I33d0ab6e167549a6499eaf6499b5a5f10d777336
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6097891
Auto-Submit: Andres Olivares <andoli@chromium.org>
Reviewed-by: Adam Raine <asraine@chromium.org>
Commit-Queue: Andres Olivares <andoli@chromium.org>
chrome:// pages do not target mobile devices, yet have been a
frequent source of bug reports for device mode.
When the user navigates to a chrome:// page, device mode is turned off
(if on) and disabled. If device mode was previously (in the current
session) on when navigating to a chrome:// page, it will be turned on
again when navigating to a non-chrome:// page.
Fixed: 40186276
Change-Id: I7d9ddb2874b91ca04813d5135eb1da8f495a2e16
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6110495
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
These markers are really noisy, so we decided to remove them. But adding
NAV since it seems useful to see how the trace is broken up into
navigations at-a-glance.
The minimap component attempted to render the NAV markers, but since
they were not marked as "tall" it never rendered.
Also align the color used for the navigationStarted event type to be the
same as the marker color (black, not orange). Similar for the other
page load metrics.
Bug: 383368162
Change-Id: I75eed42d8ab33e27d8205dc560bf7d95371a652c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6084879
Commit-Queue: Connor Clark <cjamcl@chromium.org>
Reviewed-by: Adriana Ixba <aixba@chromium.org>
Reviewed-by: Paul Irish <paulirish@chromium.org>
By using the output of the AsyncCallStacksHandler. One noticeable change
from the UI is that since we don't need specific JS entrypoints for
these events (setTimeout: InstallTimer -> TimerFire, rAF:
RequestAnimationFrame -> AnimationFrameFired, etc.), the initiated
arrows now follow this pattern:
js call -> FunctionCall. Where js call is the profile call for the
scheduling function (e.g. setTimeout or requestAnimationFrame) and
FunctionCall is the entry point for the JS task that was scheduled.
I'd argue an improvement because we are consistent across JS
schedulers, without the need for specific entrypoints for each
scheduler.
Bug: 381391955
Change-Id: I687b2c00104dde8d942b68508cfca0f072224499
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6054289
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Andres Olivares <andoli@chromium.org>
Update the @typescript-eslint - eslint-plugin and parser to v7.18.0
cia incremental patches.
This is the last version before breaking changes need to start be applied to the infrastructure.
Needed to update EsLint to v8.56.0 as required by the above major v7.
Only one new error was uncovered in test file and fixed.
No-Presubmit: true
Bug: none
Change-Id: I4e4fe265b82deeb49786c5bf3e154dac8fcfecbd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6054130
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
Benedikt Meurer
