Enabling this is required for rules that need to use the types as
resolved by the TypeScript compiler.
The no-floating-promises rule was missing some stuff due to missing
types, so this CL resolves that too. Also, return-await kicked up more
stuff.
A warm run of `npm run lint` went from ~23s to ~35s on my M1 Mac.
Bug: 406518012
Change-Id: I0c413e2ca14ee903851fd8404e490335c7f8aae0
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6397499
Reviewed-by: Nikolay Vitkov <nvitkov@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
This also simplifies the insight shape closer to how we use it in RPP,
and how we will use it in LH. This also simplifies some tests.
This modifies how we generate eventIDs when grouping by 3P. This fixes a
bug where when grouping by 3P, generateEventID can incorrectly group
events of different entities.
This fixes:
- misalignment in main thread times insight<->3P table
(by using same data source, including instant events, filters)
- incorrect event grouping: breaking bottomUp button and causing further
incorrect selftime/transfersize (bottomUp tree node ID generation)
Bug: 394651390
Change-Id: I1660a5b5b9a90be89815aad858caea94f153eabb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6341914
Reviewed-by: Paul Irish <paulirish@chromium.org>
Commit-Queue: Paul Irish <paulirish@chromium.org>
This CL adds a custom browser wrapper that starts the browser using
Puppeteer instead of letting Karma to directly start the browser. The
wrapper also exposes a binding that allows the test code to capture a
screenshot of the test DOM. The helper reuses existing screenshot
assertions and reports the result back to the test code.
This CL also adds args to improve stability of screenshots and
fixes the font to be a Roboto font loaded from Google Fonts.
To test: `npm run test --
front_end/panels/ai_assistance/components/UserActionRow.test.ts`
Bug: 401489541
Change-Id: I04889d0f0caa5c468fd35f98c66b0e6ac393de18
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6330749
Auto-Submit: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Danil Somsikov <dsv@chromium.org>
Reviewed-by: Danil Somsikov <dsv@chromium.org>
This CL reduces retries to 1 (no-retries) and the threshold for diffs to 0.1. This CL
also adds the following flags that should help to render in a more
stable way:
- `--disable-font-subpixel-positioning` disables subpixel positioning for fonts.
- `--disable-lcd-text` disables subpixel antialiasing.
- `--force-device-scale-factor=1` forces device scale factor to be 1.
- `--hide-scrollbars` hides scrollbars which might affect rendering.
Also, this CL imports a Roboto web font into component docs and adds a
special CSS class to force all fonts to be the same font (see
front_end/design_system_tokens.css and
front_end/ui/components/docs/component_docs_styles.css).
Bug: 401489541
Change-Id: I94e6a733d63459d1692197536511dad199ee168b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6342613
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This CL removes retries for test failures during the main test
run and let's the flakiness exoneration step run the failed tests
with retries.
This CL also adds a test argument called `--retries` that configures
the number of retries for failed tests for all mocha-based tests.
Bug: none
Change-Id: Id06756151cf3aeddd35db1d64dc426daa4720522
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6257655
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Justification:
- It's not super clear that disabling the insights tab means all the
insights are passing.
- The information in passed insights can be somewhat useful
- If there aren't any insights then there probably isn't anything
worth annotating either.
- Auto switching to annotations tab makes annotations the default
tab for the next trace loaded, which could have useful insights.
This does not affect the behavior of RPP when dealing with the brief
pre-navigation period before record and reload runs. This <50ms
period will still be excluded from the insight set entirely.
Bug: None
Change-Id: Ic224b5048446b84b6cbe76d2512607c33614c5a3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6220265
Auto-Submit: Adam Raine <asraine@chromium.org>
Commit-Queue: Connor Clark <cjamcl@chromium.org>
Commit-Queue: Adam Raine <asraine@chromium.org>
Reviewed-by: Connor Clark <cjamcl@chromium.org>
- Scrolling was mostly buggy due to a hardcoded row height in DataGrid (20), whereas our rows were not. It's dynamic now and doesn't force a layout thrash either.
- All of TimelineTreeView styles have been in timelinePanel.css, but due to shadow DOM, the 3P table wasn't using them. This lead to some unpredictability. Now, 3PTTV extends the component _and_ its styles.
- This included moving 3P table styles from timelineSummary.css to timelinePanel.css. That said, I've adjusted 60% of those styles, too.
- Reduced DOM complexity of the summary: fewer containers, removed use of slots. Also removed a div within .entity-badge
- A few renames to help distinguish Details (the pane with tabs), Summary (the first tab which is often used to show the _details_ of a trace event), the Category Summary (the Scripting/Rendering/etc numbers), and Range Summary (a container holding the Category Summary and 3P table, side by side)
- Pixel-perfect vertical rhythm, matching mocks: https://screenshot.googleplex.com/C2Pkr5anVgU3F5o (That was fun :)
- Changed how layout of the bottom-up button works, to get more predictable layout behavior.
Change-Id: Ia92a4a78e17813e1ce9c64d313e2a978f9aaf7d5
Bug: 388458798
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6221821
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Adriana Ixba <aixba@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Also, improve the summarizing function: where before if there was no
network request for a given trace bounds, no main thread activity would
be accounted for in the insight. Now, 3p info is summarized in two
passes: first looking at the main thread activity, and then looking at
the provided network requests.
Should have no impact on ThirdPartyTreeView, as that currently uses a
parallel interface for getting 3p information.
Bug: 352244718
Change-Id: I2774071d0334755f3c4df8ff9995e56e8d12e3e7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6209308
Commit-Queue: Connor Clark <cjamcl@chromium.org>
Reviewed-by: Adam Raine <asraine@chromium.org>
Auto-Submit: Connor Clark <cjamcl@chromium.org>
Toggling the setting used to call a bunch of methods from
TimelineFlameChartView to rebuild the timeline to include/exclude
custom tracks. Thus it was hard to keep track of the functions
that needed to be called to ensure all UI items are reset and rebuilt
properly. For this reason, overlays weren't being rebuilt after the
setting was toggled.
This CL aims to simplify this by extracting the methods that build the
data in TimelineFlameChartView into a dedicated `refresh` method, which
is called when the trace model is set and when the setting is toggled.
Drive-by: make TimelinePanel more unit test friendly by accepting a trace model on instantiation and update old screenshot tests.
Fixed: 391328289
Change-Id: If9b89a36183821f28f7e8c8199eae84cc4d979ba
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6179454
Commit-Queue: Andres Olivares <andoli@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@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>
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>
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>
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>
Connor Clark
