chrome-devtools-frontend 1.0.1402249 → 1.0.1418433

package/config/gni/devtools_image_files.gni

@@ -26,6 +26,7 @@ devtools_svg_sources = [
   "3d-rotate.svg",
   "accelerometer-back.svg",
   "accelerometer-front.svg",
+  "account-tree.svg",
   "align-content-center.svg",
   "align-content-end.svg",
   "align-content-space-around.svg",
@@ -44,9 +45,11 @@ devtools_svg_sources = [
   "align-self-stretch.svg",
   "animation.svg",
   "arrow-back.svg",
+  "arrow-collapse.svg",
   "arrow-down.svg",
   "arrow-drop-down-dark.svg",
   "arrow-drop-down-light.svg",
+  "arrow-drop-down.svg",
   "arrow-forward.svg",
   "arrow-right-circle.svg",
   "arrow-up-down-circle.svg",
@@ -107,6 +110,7 @@ devtools_svg_sources = [
   "devtools-thumbnail.svg",
   "devtools-tips.svg",
   "devtools.svg",
+  "difference.svg",
   "dock-bottom.svg",
   "dock-left.svg",
   "dock-right.svg",
@@ -153,8 +157,10 @@ devtools_svg_sources = [
   "gear-filled.svg",
   "gear.svg",
   "gears.svg",
+  "global.svg",
   "google.svg",
   "goto-filled.svg",
+  "grid-on.svg",
   "group.svg",
   "heap-snapshot.svg",
   "heap-snapshots.svg",
@@ -183,8 +189,10 @@ devtools_svg_sources = [
   "justify-items-start.svg",
   "justify-items-stretch.svg",
   "keyboard-arrow-right.svg",
+  "keyboard-full.svg",
   "keyboard-pen.svg",
   "keyboard.svg",
+  "label.svg",
   "large-arrow-right-filled.svg",
   "layers-filled.svg",
   "layers.svg",
@@ -203,7 +211,10 @@ devtools_svg_sources = [
   "mop.svg",
   "mouse.svg",
   "network-settings.svg",
+  "node-stack-icon.svg",
   "open-externally.svg",
+  "override.svg",
+  "palette.svg",
   "pause-circle.svg",
   "pause.svg",
   "pen-spark.svg",
@@ -213,6 +224,7 @@ devtools_svg_sources = [
   "performance-panel-time-range.svg",
   "performance.svg",
   "person.svg",
+  "photo-camera.svg",
   "play.svg",
   "plus.svg",
   "policy.svg",
@@ -254,10 +266,12 @@ devtools_svg_sources = [
   "symbol.svg",
   "sync.svg",
   "table.svg",
+  "terminal.svg",
   "thumb-down-filled.svg",
   "thumb-down.svg",
   "thumb-up-filled.svg",
   "thumb-up.svg",
+  "tonality.svg",
   "top-panel-close.svg",
   "top-panel-open.svg",
   "touch-app.svg",

package/config/owner/INFRA_OWNERS

@@ -4,4 +4,5 @@ jacktfranklin@chromium.org
 liviurau@chromium.org
 machenbach@chromium.org
 mathias@chromium.org
+paulirish@chromium.org
 szuend@chromium.org

package/config/typescript/tsconfig.eslint.json

@@ -14,6 +14,7 @@
     "../../front_end/**/*.ts",
     "../../inspector_overlay/**/*.ts",
     "../../scripts/protocol_typescript/*.ts",
-    "../../test/**/*.ts"
+    "../../test/**/*.ts",
+    "../../extensions/**/*.ts",
   ]
 }

package/docs/README.md

@@ -15,6 +15,10 @@ below.**
 
 [TOC]
 
+## Chromium DevTools Playbook (aka Work With Us)
+
+* See the [playbook](./playbook.md) for step-by-step instructions on how to work with Chromium DevTools to implement your idea.
+
 ## Document Index
 
 ### Design Documents

package/docs/cookbook/localization.md

@@ -210,7 +210,7 @@ contains some other DOM element.
 clickTheRecordButtonSToStart: 'Click the reload button {PH1} to reload or record button {PH2} start capturing coverage.',
 
 // Element with localizable content containing two DOM elements that are buttons
-const reloadButton = UI.createInlineButton(UI.Toolbar.createActionButtonForId('coverage.start-with-reload'));
+const reloadButton = UI.createInlineButton(UI.Toolbar.createActionButton('coverage.start-with-reload'));
 const recordButton = UI.createInlineButton(UI.Toolbar.createActionButton(this._toggleRecordAction));
 message = i18n.i18n.getFormatLocalizedString(str_, UIStrings.clickTheReloadButtonSToReloadAnd, {PH1: reloadButton, PH2:recordButton });
 ```

package/docs/get_the_code.md

@@ -43,23 +43,6 @@ You can disable type checking for TypeScript by using `devtools_skip_typecheck`
 gn gen out/fast-build --args="devtools_skip_typecheck=true"
 ```
 
-#### Faster incremental builds & CSS hot reload
-In addition to that, you can enable CSS hot reload while using `watch` script with `devtools_css_hot_reload_enabled` argument:
-```bash
-gn gen out/fast-build --args="devtools_css_hot_reload_enabled=true"
-```
-
-with this and `devtools_skip_typecheck=true` in place, you can use `watch` script by:
-```bash
-npm run watch -- --target=fast-build
-```
-which will automatically apply CSS changes & instantly build changed TS files.
-
-> Caution! `watch` script is not based on `ninja` thus the build output and behavior
-> might differ with the official ninja build. In addition to that,
-> there might be some cases that `watch` build doesn't reliably handle, so you
-> might need to run `autoninja` and restart the script from time to time.
-
 ### Update to latest
 
 To update to latest tip of tree version:

package/docs/playbook.md

@@ -0,0 +1,176 @@
+# Chromium DevTools Playbook (aka Work With Us)
+
+This document serves as the Chrome DevTools Playbook and thereby provides guidance on how to work with Chrome DevTools, the types of Chrome DevTools support available, how you and your team can take advantage of that support to contribute features, and how to get help when in doubt of the type of support needed or if you need more support.
+
+## Getting Started
+
+*   If you are a **Googler** see [go/chrome-devtools/work-with-us](go/chrome-devtools/work-with-us) for additional information.
+*   If you're a **first-time contributor** and would like some guidance to begin with, please jump to the [First Time Contributor](#first-time-devtools-contributor) section at the end of this document.
+*   If you are only looking for **DevTools documentations**, here is the [list](#devtools-documentation).
+
+To help us understand your needs and collaborate effectively, please follow the steps below.
+
+**Answer three preliminary questions:**
+
+1.  [What level of debuggability do you need?](#what-level-of-debuggability-do-you-need)
+2.  [What is the scope of your feature request?](#what-is-the-scope-of-your-feature-request)
+3.  [What is your preferred collaboration mode?](#what-is-your-preferred-collaboration-mode)
+
+Depending on your answers, you can do one of the following:
+
+*   [Contact DevTools team](#contact-devtools) to discuss your feature request, **OR**
+*   Directly design your feature, write your design doc and share with DevTools team, **OR**
+*   Directly write your CL(s) and submit them for review.
+
+## Contact DevTools
+
+The team uses a public mailing list for technical discussions, questions, and announcements.
+
+*   **Email address:** [devtools-dev@chromium.org](mailto:devtools-dev@chromium.org)
+*   **Web archives:** [devtools-dev](https://groups.google.com/a/chromium.org/g/devtools-dev)
+
+### Points of Contact for Specific Topics
+
+For certain topics, there are dedicated points of contact (PoCs) within the DevTools team, who are considered experts and have guided initiatives within these areas in the past.
+
+| Topic                                 | PoC             |
+| ------------------------------------- | --------------- |
+| Web Compass, Interop, and Baseline    | pfaffe@chromium.org         |
+| UI Capabilities                       | changhaohan@chromium.org    |
+| Performance                           | paulirish@chromium.org      |
+| JavaScript                            | szuend@chromium.org         |
+| WebAssembly                           | pfaffe@chromium.org         |
+| Security                              | dsv@chromium.org  |
+| Network                               | dsv@chromium.org  |
+| Extensions                            | pfaffe@chromium.org         |
+
+
+## What level of debuggability do you need?
+
+A feature is debuggable in DevTools if developers can use DevTools to more easily identify and fix a bug related to this feature. In some cases, debuggability is important for a feature's adoption, especially when a feature is complex and popular. There are three levels of debuggability, as follows.
+
+### No Debuggability
+
+DevTools doesn't offer any special support for the Web Platform Feature, but using the feature doesn't break DevTools.
+
+### Basic Debuggability
+
+DevTools helps developers understand the use of a feature.
+
+*   **Basic debuggability for CSS features:** The feature properties are displayed and, if applicable, are editable. If the feature includes cross references, references are linkified where appropriate.
+*   **Basic debuggability for Web APIs:** Objects can be inspected in the sources panel (scope view, editor popover, console) and function calls can be made from the console.
+
+### Extended Debuggability
+
+DevTools offers dedicated tooling for Web Platform APIs. These tools provide helpful hints, educating developers on how to use these features effectively. Extended tooling support usually follows our [standard feature development process](go/chrome-devtools/development-process).
+
+*   **Extended debuggability for CSS:** DevTools clearly shows the user the different usage options for a feature and offers a non-text UI to configure it where possible (e.g., color picker, flexbox picker).
+*   **Extended debuggability for Web APIs:** DevTools offers first-party debugging support for a feature, e.g. through automatic breakpoints.
+
+## What is the scope of your feature request?
+
+Defining the scope of the feature request helps us better understand how to allocate resources, and choose the most appropriate collaboration mode. Specifically, if you need extended debuggability support, please think about the following:
+
+*   the minimal viable product needed to ensure a smooth adoption of the feature by developers
+*   the v1.0 of your feature
+*   nice-to-haves and out-of-scope features
+*   the responsibility to maintain the feature
+
+## What is your preferred collaboration mode?
+
+To scale the tooling support to the number of developer products and APIs being launched throughout Chrome (in particular the various new Web Platform APIs being introduced year-by-year), the Chrome DevTools team has created a guiding framework on how priorities are supported and provided more options for supporting teams.
+Each initiative is owned by the feature team. Each engagement will have a definitive level of support defined out of the following categories:
+
+### Self-service
+
+In this self-service model, feature teams are responsible for designing and implementing tooling support, using the provided [documentation](#devtools-documentation). The DevTools team will not actively follow the project but will answer questions, similar to office hours. This type of support is designed to scale the tooling support by providing guidance and resources to product and engineering teams.
+
+**Example:** [Web Audio extension](https://chromewebstore.google.com/detail/audion/cmhomipkklckpomafalojobppmmidlgl?pli=1)
+
+### Consultation
+
+The Chrome DevTools team will consult the feature team on the right solution, in particular on the right usage of DevTools/CDP API, and the design of runtime introspection capabilities. The UI of the solution will either be
+
+*   Chrome Extension,
+*   Chrome Internals page, or
+*   a separate tool.
+
+There is no meaningful expectation to change the DevTools frontend.
+
+**Example:** Privacy & Security panel
+
+### Review + Upstream
+
+The feature team does the implementation of the DevTools frontend pieces and relevant backend services required for debugging. The Chrome DevTools team does the reviews and consultations required to get the CLs landed and folding nicely into our tool surfaces (e.g. does it meet the [Chromium DevTools UI feature checklist](./checklist/ui.md)?).
+
+**Example:** [Early Hints DevTools support](https://docs.google.com/document/d/1IAbWeu9cj37EYaIvFpWOtnPFLxorO2YVHnxxdX0EwOU)
+
+### 50/50 split
+
+The Chrome DevTools team does the implementation of the DevTools frontend pieces. The feature team does the implementation of the backend services and plumbing required for debugging to be used in the frontend, most likely the CDP methods et. al.
+
+**Example:** [Autofill DevTools MVP](http://go/chrome-devtools:autofill-mvp-prd)
+
+### Fully owned
+
+The Chrome DevTools team does the implementation and design of frontend and backend pieces.
+
+**Examples:** Core Web Vital support in Lighthouse and DevTools, [Modern CSS color features in DevTools](http://go/chrome-devtools:modern-color-prd)
+
+## What are the expectations regarding maintenance?
+
+Any new feature comes with the potential of introducing new bugs (potentially even breaking somewhat unrelated workflows unintentionally).
+
+For any of the collaboration modes listed above except *Fully owned*, the Chrome DevTools team expects the feature team to maintain the tooling aspects of their feature by fixing any bugs that result from the MVP / 1.0, independent of whether these are frontend or backend bugs (except in case of 50/50 split where the Chrome DevTools team will own the frontend issues), for at least a period of **3 Chrome milestones** (since the successful launch).
+
+Additionally the Chrome DevTools team relies on the feature team as the domain experts for any domain-specific bugs that need to be tackled (independent of whether it’s frontend or backend related).
+
+## DevTools Documentation
+
+Depending on your answers above *and/or* your current feature stage, you may need one of these documents below.
+
+### basic level of debuggability + self-service collaboration mode
+
+*   [DevTools support checklist for Blink Intents](https://chromium.googlesource.com/devtools/devtools-frontend/+/main/docs/checklist/README.md)
+*   [DevTools support checklist for JavaScript features](https://chromium.googlesource.com/devtools/devtools-frontend/+/main/docs/checklist/javascript.md)
+*   [DevTools support checklist for WebAssembly features](https://chromium.googlesource.com/devtools/devtools-frontend/+/main/docs/checklist/webassembly.md)
+
+### Feature request initial review or consultation mode
+
+*  [Contact us](#contact-devtools)
+
+### Feature design phase
+
+*   [DevTools UI feature checklist](./checklist/ui.md)
+*   [UX Style Guide](./styleguide/ux/README.md)
+
+## Coding phase
+
+*   [Get the Code](./get_the_code.md)
+*   [Contribution Guide](./contributing/README.md)
+*   [UX Style Guide](./styleguide/ux/README.md)
+*   [Testing Guide](../test/README.md)
+*   [Cookbook](./cookbook/README.md)
+*   [Visual logging in DevTools](../front_end/ui/visual_logging/README.md)
+*   [Style Guides](./styleguide/README.md)
+*   [Architecture of DevTools](architecture_of_devtools.md)
+*   [Chrome DevTools Protocol (CDP)](devtools-protocol.md)
+*   [Resource management in DevTools](resource_management.md)
+
+## First time DevTools contributor?
+
+If you haven't worked with the Chrome DevTools team before, or if you're unsure where your feature fits, please follow the steps outlined below.
+
+1.  Ask yourself who will be using your features and what kind of tooling support they might need to ensure a smooth adoption of your feature.
+    Try to think in terms of tasks and challenges developers may face, not UI elements.
+2.  Write a short email to devtools-dev@ with your best shot at answering those questions. It doesn't have to be perfect, and it is not a questionnaire
+    you need to fill to satisfy some formal process. We are mostly interested in a positive end user experience and are willing to work with you together
+    to achieve that.
+3.  We will get back to you with some initial thoughts and might ask to formalize your ideas in a design document.
+4.  Most likely we will ask you to book an office hours with our UXD to discuss your feature’s UX, so that developers have a consistent experience on
+    DevTools. Complex features where developers have to be introduced to significant new capabilities may take multiple iterations. It’s important to
+    get this step right.
+5.  Depending on the details, we will probably ask you to help us get the information exposed over the
+    [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/). We might also ask you to write a few straightforward CLs to
+    implement the UI. Don't worry, we won't ask you to re-architect our code to accommodate your feature. We will also offer all the support you
+    need along the way.

package/docs/styleguide/ux/README.md

@@ -9,6 +9,7 @@ user interface.
 
 1. [How to organize UI](organizing.md)
 1. [How to style UI](styleguide.md)
+1. [How to (re)use common UX patterns](patterns.md)
 1. [How to write UI text](writing.md)
 1. [How to format numbers](numbers.md)
 1. [Glossary](glossary.md)

package/docs/styleguide/ux/components.md

@@ -137,6 +137,58 @@ button.addEventListener('click', event => onClick(event));
   * [Icon
     buttons](https://www.figma.com/design/A5iQBBNAe5zPFpJvUzUgW8/CDT-design-kit?node-id=571-616&m=dev)
 
+## Combo Boxes
+
+![Combo Box component](images/combo-box-variations.png)
+
+### Usage
+
+#### Developer guidelines
+
+##### Dos and Don'ts
+
+###### Do
+
+  * Use [`<select>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select)
+    with [`<option>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option)
+    and [`<optgroup>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/optgroup)
+    if necessary, together with core styles.
+  * Override inherited `width` with CSS if necessary.
+
+###### Don'ts
+
+  * Override the default colors.
+  * Introduce custom select components.
+
+##### Developer examples
+
+###### Primary button
+
+Usage with lit-html:
+
+```js
+html`<select aria-label="Choose your champion"
+             @onchange=${onChange}>
+  <option jslog=${VisualLogging.item('hamster').track({click: true})}
+          value="Hamster">Hamster</option>
+  <option jslog=${VisualLogging.item('mouse').track({click: true})}
+          value="Mouse">Mouse</option>
+  <option jslog=${VisualLogging.item('cat').track({click: true})}
+          value="Cat">Cat</option>
+</select>`
+```
+
+Usage with the imperative API:
+
+```js
+const select = UI.UIUtils.createSelect('Choose your champion', [
+  'Hamster',
+  'Mouse',
+  'Cat',
+]);
+select.addEventListener('change', event => onChange(event))
+```
+
 ## Radio Buttons
 
 ![Radio Button component](images/radio-buttons-variations.png)
@@ -171,7 +223,7 @@ html`<label><input type="radio" name=${name} jslog=${jslog}>${title}</label>`
 Usage with the imperative API:
 
 ```js
-const {label, radio} = UI.UItils.createRadioButton(name, title, jslogContext);
+const {label, radio} = UI.UIUtils.createRadioButton(name, title, jslogContext);
 radio.addEventListener('change', event => onChange(event))
 ```
 
@@ -211,7 +263,7 @@ html`<input type="range"
 Usage with the imperative API:
 
 ```js
-const slider = UI.UItils.createSlider(min, max, tabIndex);
+const slider = UI.UIUtils.createSlider(min, max, tabIndex);
 slider.addEventListener('change', event => onChange(event))
 ```
 

package/docs/styleguide/ux/patterns.md

@@ -0,0 +1,87 @@
+# How to (re)use common UX patterns
+
+There are some common UX patterns in DevTools, such as linking from one place to another, loading states, or dialogs. Please refer to this guide if the pattern you intend to use can be found here.
+
+Please also note that while some patterns can be summarized into a [component](components.md), this guide focuses more on the end-user experience than the actual implementation.
+
+## Overlays
+
+Overlays are visual aids that are superimposed on the webpage you're inspecting. These overlays provide extra information or highlight specific aspects of the page to help you with debugging and development.
+
+### What can they do?
+Draws non-interactive overlays on inspected page directly.
+
+### When should you use them?
+When you want to visually annotate DOM elements, for example, for measurements, guides, column, anchors, etc. This has the benefit of almost no context switch since the debugging information is right next to the debugged target.
+
+### Examples
+
+Complicated layout concepts such as Flexbox and Grid can use overlays to help developers understand these layout intricacies better by showing their alignment, order, and sizing.
+
+### Things to consider
+
+Overlays are not interactive yet, and is a bit tricky to implement.
+
+## Linkability
+
+### What can they do?
+
+A linkable text or visual element can bring developers to another place when interacted.
+
+### When should you use them?
+
+Linkability can be added to visual elements when you want to help developers understand the relationship between multiple pieces of information in DevTools, or provide a quick way to jump from a
+
+### Common patterns and their implementations
+
+- Hyperlink, underlined: jump to another panel, or open a tab with a URL
+- Anchorlink, underlined: jump to another element (CSS variables, popover)
+- Button, not underlined: for example the node in the Animations panel. They just "highlight" something in the Elements panel, but you don't jump around.
+
+On hover, linkable texts should show a pointer cursor.
+
+### Examples
+
+Certain CSS and DOM features that span across different elements or style rules have links between them, such as "popovertarget" attributes in the DOM tree, and CSS variables.
+
+### Things to consider
+
+Underlines can be visually distracting when used heavily, and we advise that when there tends to be a lot linkable elements, you _only_ show the underline on hover. A canonical example is CSS variable linking in the Styles tab.
+
+## Visual hints for non-default states
+
+### What can they do?
+
+Visual hints signify to users that something is not in its default state with some visual hints, such as greyed-out texts, yellow warning icons, or crossed-out texts. They do not necessarily mean something is not correct: think about the text style for comments in IDEs.
+
+### When should you use them?
+
+You can use them when you want to help developers realize something is not in the default state, and optionally guide them how to fix it. Some states are called “default” for a reason: you write `color: red` and will expect your element’s text to turn red. If it does not turn red, it is in a non-default state. Anything that is acting abnormal is something we should flag to the users with visual hints so that they know what went wrong more easily.
+
+Currently, these visual hints for non-default states usually exist in the Elements panel and the Sources panel, where developers often iteratively modify their page's code to debug.
+
+### Common patterns and their implementations
+
+#### Pale Text
+
+We show pale texts for:
+- selectors: the Styles tab shows matched selectors in regular text and unmatched ones in pale text.
+- non-inherited properties that are shown because they exist within the same CSS style rule that happens to contain an inherited property for an element.
+
+#### Crossed-out text
+- We strike out the entire declaration when
+it's commented-out, e.g. toggled inactive,
+superseded by another declaration (with a higher specificity, etc.).
+- We strike out inactive values, such as inactive custom variable fallbacks, inactive min()/max() values, and inactive position-try fallbacks.
+
+#### Italic text
+
+We show italic texts for style texts that cannot be edited. For example, UA stylesheets cannot be edited, and they are shown in italic texts.
+
+### Examples
+
+The Styles tab's [public documentation](https://developer.chrome.com/docs/devtools/css/issues) contains illustrative examples of how visual hints are used here.
+
+### Things to consider
+
+Visual hints, when used heavily, will create visual noises and become less effective for warning people. Please consider how common the non-default state is before using visual hints on them.

package/docs/styleguide/ux/styles.md

@@ -2,18 +2,29 @@
 
 [TOC]
 
+## Design tokens
+
+Design tokens are the building blocks for our design system, and they define
+values like colors, fonts, and sizes. Use these tokens instead of hard coded
+values. You can find the tokens in
+[design\_system\_tokens.css](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css).
+
+*Note*: In rare cases we allow for one-off tokens that are used in the code,
+e.g. if requested explicitly by our UX team. They are defined in
+[application\_tokens.css](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/application_tokens.css).
+
 ## Colors
 
 We define three sets of color token types, **reference/palette tokens**,
 **system tokens**, and **application tokens**.
 
 [**Reference or palette
-tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/tokens.css)
+tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css)
 (e.g. `--ref-palette-X`) are a set of base colors that get updated on [Chrome
 color theme change](###) and should not be directly used.
 
 [**System
-tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/themeColors.css)
+tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css)
 (e.g. `--sys-color-X`) are a set of semantic tokens (use is often clear from
 name e.g. `--sys-color-error-container`). They reference palette tokens and
 incorporate light / dark mode switches and should be used in the code directly.
@@ -21,7 +32,7 @@ You can view all system tokens in their light and dark variant when running the
 component server with `npm run components-server` under *Theme Colors*.
 
 [**Application
-tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/applicationColorTokens.css)
+tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/application_tokens.css)
 (e.g. `--app-color-X`) reference palette tokens, and add more semantic meaning
 and handle exception cases, where system tokens are not enough. Should be
 defined for both light and dark modes. An example CL that adds application
@@ -51,7 +62,7 @@ Chrome's theming differentiates between two *default* color schemes (a blue
 **default** and a **grey default**), and a number of **accent** color schemes
 (blue, purple, yellow, and so on). In DevTools, the default schemes are defined
 as `baseline-grayscale` and `baseline-default` css classes in
-[themeColors.css](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/themeColors.css).
+[themeColors.css](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css).
 The accent color schemes don't require extra color definitions and will adapt
 with the reference colors.
 
@@ -317,18 +328,18 @@ example CL that adds application tokens can be found
 ### Resources
 
   * [Reference color
-    tokens](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/tokens.css)
+    tokens](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css)
   * [System color
-    tokens](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/themeColors.css)
+    tokens](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css)
   * [Application color
-    tokens](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/applicationColorTokens.css)
+    tokens](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/application_tokens_.css)
   * [Color definitions in the CDT
     Figma](https://www.figma.com/design/A5iQBBNAe5zPFpJvUzUgW8/CDT-design-kit?node-id=337-5217&m=dev)
 
 ## Sizes
 
 [**System
-tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/ui/legacy/designTokens.css)
+tokens**](https://crsrc.org/c/third_party/devtools-frontend/src/front_end/design_system_tokens.css)
 include a set of tokens to be used for sizes, ranging from `--sys-size-1` (which
 corresponds to a single pixel) to `--sys-size-41` (which corresponds to the HD
 resolution width).