Prior to this change, the generated CSS files would show up un "no
domain" in DevTools-on-DevTools, rather than in the correct paths
(next to the source code). This is because we inject the CSS via
`<style>` tags (or in some cases still adopt them to the shadow
root), and put a relative path into the `sourceURL` annotation.
DevTools-on-DevTools is not able to reconstruct the proper URL in
these cases, because it doesn't know the contextual base URL.
With this change, we use `import.meta` to construct the proper
URL at the time when importing the `.css.js` file, and stick that
into the `sourceURL` annotation.
Bug: 391381439
Change-Id: Ia965faa19d5119a2f70f840cf20d8d5b914856d7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6221305
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
This is the first step in the CSS unification, which adjusts the build
system to only spit out "legacy CSS" files, which we still turn into
constructed style sheets in various places, and which will be migrated
in a follow-up step.
In a follow up step, the `.css.legacy.js` files will also be renamed to
just `.css.js`, but for this change, it was easier to stick to this
naming scheme.
Bug: 391381439
Change-Id: I11e99c9dfcfd6adfca95242cbe152fed5ac3c107
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6219314
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
This merges the definitions that were in design_tokens into
theme_colors.css and application_color_tokens.css.
In a follow up, we'll rename these two (theme_colors and
application_color_tokens). Keeping the same name here in order to
keep the diff easier to read for review purposes.
Bug: 390330089
Change-Id: Ia8510ca0818d31409250c1d5e6ef67897e6fc193
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6203922
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kateryna Prokopenko <kprokopenko@chromium.org>
This is the first part of our goal to merge the token css files
(token.css, theme_colors.css, design_tokens.css and
application_color_tokens.css). In the end, we want to end up
with two css files only.
This CL makes the following changes:
1. Move the content from `tokens.css` into `theme_colors.css`
2. Remove `tokens.css`
Note that this CL is simply moving the content for simplicity of
reviewing.
More clean ups will follow.
Bug: 390330089
Change-Id: Id06de578b1f5bf5f6dda7674e356a2c9f0463e94
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6189457
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
This is the next step in unifying the way we inject CSS. While we should
probably have a proper `<devtools-text-button>` component instead of the
`.text-button` styles, I'm leaving that as a refactoring for later, and
for now, move the styles out of the legacy UI bundle and into the button
component.
Bug: 391381439
Change-Id: Id4708319dbfe2d609da0947ef9e3f7692723393b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6189456
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
This CL updates the auto-run tool to support performance examples that
have an entry label annotation. The tool will now select that entry,
parse the prompt out of the HTML file, and execute the AI Assistance
against it.
The tool can find the metadata from the trace / HTML comments, and it is
able to download and import the trace into DevTools.
Most of the work here was in the downloading & metadata generation; the
actual AI execution is very similar, we just select an event in the Perf
Panel rather than inspect an element.
Bug: 383120286
Change-Id: I7d6ebff3a0577c46cb87c8fa57f1fbad6c475f44
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6172722
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Ergün Erdoğmuş <ergunsh@chromium.org>
EsLint support .mjs file by default now. But we exclude them from
running previously in our script.
Disabled the `es-modules-import` rule for our script folder
as it's not relevant there.
Added types comment to the EsLint rules.
This should make it easier to build and understand the current rules.
Bug: none
Change-Id: I448efdb055c9cc107e3bced9b3febe5eb226bcf6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6177719
Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
The `JSONEditor` was previously using `LitElement`, which is not in line
with how we want to build UI in the future. This does the minimal
changes to turn it into a `UI.Widget.Widget` instead and also fixes the
build dependencies accordingly.
Bug: 390071004, 301364727
Change-Id: Ia01fb731e437ffb6fd8c435b905fe5973ad5f48a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6170726
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
This CL adds typechecking to the command line tool; although we had some
type supports there was no erroring if you did something wrong or used a
function that didn't exist.
This does make the code slightly more verbose but I do think it's worth
it. I don't ever expect this to be typechecked on CQ, but it does cause
errors to appear in the editor which will help folks working on it.
Bug: 383120286
Change-Id: If4236c2e20e244be6b0abaaad4b7c90c88cb5124
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6172331
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Ergün Erdoğmuş <ergunsh@chromium.org>
Reviewed-by: Ergün Erdoğmuş <ergunsh@chromium.org>
This CL introduces the ability for comments in our examples to have any
key/value pairs, whilst also supporting the existing syntax. This means
we can define comments for examples either as:
```
<!--
Why is this text not centered?
# Because it has text-align: left; applied
-->
```
But now also:
```
<!--
Prompt: Why is this text not centered?
Explanation: Because it has text-align: left; applied
-->
```
The resulting object will be:
```
{
prompt: 'Why is this...',
explanation: 'Because...'
}
```
(In the old syntax, we assume lines with no prefix are prompts, and
lines with a `#` are part of the explanation).
Additionally, this CL also supports any random `A:B` key pairs, and also
ensures that multiple lines are supported. These will be used to provide
more context for other examples.
Bug: 383120286
Change-Id: Ib12c94c74d6045d845aad2edfb38d1dfb5166fec
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6171178
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Ergün Erdoğmuş <ergunsh@chromium.org>
Ahead of making some changes to the splitComments function, this CL
moves it into its own file that can easily be tested. The function has
also been renamed to `parseComments` which is a bit more accurate.
I considered just exporting the function from auto-run.js, but
auto-run.js assumes it is invoked on the command line, so rather than
restructure it to support being imported for tests, it was easier to
move the function into a separate helpers file.
Bug: 383120286
Change-Id: Icdd3a730def908fa180152981f2765cbf6e55c6d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6171176
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Ergün Erdoğmuş <ergunsh@chromium.org>
Accidentally importing something as `foo//bar.js` (rather than
`foo/bar.js`) should not matter, and indeed both the TS build and
ESBuild compile fine. However you get an error when running DevTools at
runtime. What's unfortunate is that the error is very non obvious and it
took me ages to realise that the root of it was an accidental `//`.
This CL adds a check for this to the existing import rule and a test.
Fixed: 346966388
Change-Id: I3922a58b89ce639fc619c0e2b83cd14f3fe993cb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6157259
Commit-Queue: Andres Olivares <andoli@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Andres Olivares <andoli@chromium.org>
This adds a helper function to avoid sprinkling casts to
`Platform.DevToolsPath.UrlString` all over our unit test
suite, combined with an ESLint rule to enforce that we
use this helper consistently.
This leads to much more readable test code for unit tests
that are concerned with APIs that take `UrlString`s, and
the code is more consistent.
Bug: 323797639
Change-Id: I6d797c0db9e5bd2fd019b83b9a7a269c7437ebdf
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6148578
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Danil Somsikov <dsv@chromium.org>
The previous check was too restricted in that it only checked for
array literals, and didn't bother also checking for object literals.
It was also not restricted to just the `assert.strictEqual` and the
`assert.notStrictEqual` methods, and unnecessarily prevented us from
using for example `assert.hasAnyKeys` or `assert.sameMembers`, which
is clearly beneficial in various cases.
This new check also provides a fix.
Bug: 40185458
Change-Id: I1b151cf8eb594b7255c77380967aea39a46ee2cd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6110248
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Changhao Han <changhaohan@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>
Danil Somsikov