chrome-devtools-frontend 1.0.1657110 → 1.0.1660788

package/.agents/skills/devtools-ux-writing-refactor/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: devtools-ux-writing-refactor
+description: >-
+  Refactor user-facing UIStrings and localization comments in a DevTools module folder according to UX writing guidelines (child task of b/40799900). Use when simplifying wording, checking sentence case, or improving L10n comments in UIStrings for a specific folder or issue. Don’t use for general code changes or non-UIStrings files.
+---
+
+# DevTools UX writing refactoring workflow
+
+Use this skill when addressing a single UX writing refactoring task (one module folder or child issue under tracking bug [b/40799900](https://crbug.com/40799900)).
+
+## 0. Environment setup (avoid PATH errors)
+
+In DevTools Linux workspaces, `depot_tools` and `node`/`npm` may not be in `PATH` in non-interactive agent shells. Before you run Git, `gclient`, `npm`, or `git cl` commands, ensure that your environment is set up:
+```bash
+export PATH=$HOME/depot_tools:$PATH
+source ~/.nvm/nvm.sh  # Or export PATH=$(pwd)/third_party/node/linux/node-linux-x64/bin:$PATH
+```
+
+## 1. Pre-flight issue check and target scope
+
+Before you write code or modify files, check the status of the associated Buganizer issue:
+```bash
+$ISSUES render <issue_number>  # Or use buganizer MCP tools: render_issue / render_issue_with_external
+```
+* **Why?** Multiple developers and agents work on child tasks under `b/40799900`.
+* **Action required:** If the issue is marked as `FIXED`, `VERIFIED`, or `CLOSED`, is assigned to another active developer, or has an attached Change List (CL), **stop immediately and verify whether you need to address it**. Ask the user for confirmation before you override existing work.
+* **Identify target files:** If `render_issue` returns an external redaction notice, use `render_issue_with_external` to view the full bug description. The bug description typically lists the exact **Target Files** to refactor for this child task. Focus exclusively on those target files.
+
+## 2. Create a branch
+
+Create a branch dedicated to this issue from the latest `origin/main` (after you run `gclient sync`) using the DevTools version control tool:
+```bash
+git fetch origin
+git checkout origin/main
+gclient sync
+git new-branch fix-<issue_number>
+```
+* **Why?** In Chrome DevTools, don’t use standard Git commands such as `git checkout -b` or `git switch -c`. Always use `git new-branch` so that `depot_tools` and Gerrit configure tracking information correctly.
+* **Naming:** Always include the issue number in the branch name (for example, `fix-531625399`).
+
+## 3. Refactor UIStrings and localization comments
+
+Locate all TypeScript files in the target folder that define `const UIStrings = { ... }` and apply the **8-point UX writing checklist** (cross-check with official DevTools documentation at https://developer.chrome.com/docs/devtools).
+
+> [!IMPORTANT]
+> **Ignore non-localized or experimental strings:** Don’t modify strings in `const UIStringsNotTranslate = { ... }`, `lockedString`, or `i18n.i18n.lockedString`. These strings are for early-stage or experimental features that you mustn’t localize or alter during UX refactoring.
+
+### The 8-point checklist
+1. **Brevity and short synonyms:** Replace formal or lengthy words:
+   * `preserve` -> `keep` | `additional` -> `more` | `prevent` -> `stop` | `receive` -> `get`
+   * `submit` -> `send` | `modification` -> `change` | `create` -> `add` | `suitable` -> `fit`
+   * *Check sibling references:* If you change a setting name or label (for example, changing “Preserve log” to “Keep log”), search sibling files in the folder for explanatory text or status strings that reference the old name in quotes (for example, “console.clear() was prevented due to ‘Preserve log’”), and update them to match.
+2. **Cut unnecessary words:** Eliminate politeness (`please`, `sorry`), filler (`very`, `strongly`, `there is` or `there are`), and marketing fluff (`seamless`, `awesome`, `fast`, `quick`).
+3. **Contractions:** Use contractions (`don’t`, `can’t`, `isn’t`, `won’t`) instead of formal spellings (`do not`, `cannot`, `is not`, `will not`).
+4. **Curly apostrophes, quotation marks, and ellipses:** Use curly apostrophes (`’`) and quotation marks (`“ ”`) for improved readability. Use the ellipsis character (`…`) instead of three periods (`...`). Use prime (`′`) and double prime (`″`) symbols as needed for measurements like length or coordinates.
+5. **Sentence case and capitalization:** Use sentence case for headings, labels, and UI element names. Capitalize only the first word, proper nouns, product names (`Chrome DevTools`), and web APIs (`Background Fetch API`).
+   * Don’t capitalize feature names (for example, `conditional breakpoint` or `command menu`).
+   * Capitalize panel names and UX elements that are named after panels (for example, `Show Application`, `Toggle Console`, `Console sidebar`, or `Styles`).
+   * For panel names that consist of two words, capitalize only the first word (for example, `Developer resources panel`).
+   * When you use the panel name in combination with another word, capitalize the panel name but not the other word, unless it is a proper noun (for example, `Console view` or `DevTools Console`).
+   * In some cases, ambiguity exists whether a word refers to a UX element in DevTools (such as a panel name) or a concept (such as developer terminology). For example, this occurs with `console`, `issue`, or `network`. Decide based on the surrounding context and code (for example, `Console view`, `Console sidebar`, and `Console prompt` versus `console message`, `console warning`, `console log`, `copy console`, `clear console`, and `console history`; `Show Network` versus `network log` and `network filter`).
+6. **Punctuation and actionability:** Remove trailing periods from single-sentence labels or titles. Ensure that error messages instruct the user how to recover (for example, `Shorten filename to 64 characters or less` instead of `Invalid filename`). Ensure that ARIA labels and multi-sentence tooltips have consistent terminal punctuation.
+7. **Terminology (glossary):** Strictly follow standard DevTools UI terminology and letter casing (`panel`, `tab`, `drawer`, `sidebar`, `datagrid` or `table`, `action bar`, `status bar`, and `live expressions section`). Never use `pane` or call tabs `panes` in UI strings or localization (L10n) comments.
+8. **Localization (L10n) comments:** Ensure that every string in `UIStrings` has a preceding `@description` comment that explains where and when it appears. This information is used for translators who need to understand the context in which the string is used.
+   * Use precise terminology and correct letter casing (see rule 7). Ensure that the description is easy to understand and provides enough context for translators. For descriptions that are underspecified or
+   ambiguous, figure out the context by looking at the use site of the
+   string and come up with a better description.
+   * You must explicitly document all standard placeholders (`{PH1}`, `{url}`, `{index}`) with runtime data examples (for example, `@example {https://example.com} url`).
+   * *ICU plural variables:* The i18n tool automatically parses variables in ICU plural format (such as `n` in `{n, plural, =0 {No issues} ...}`) as numeric counts, so they don’t require an `@example` tag in the `@description` comment.
+   * *Terminal punctuation:* Every `@description` comment must end with a period (`.`), even if it is a single phrase or sentence.
+
+## 4. Chrome writing style guide
+
+Also consult the style guides at `google3/experimental/users/rachelandrew/tools/chrome_writing/knowledge/style/` for applicable guidelines.
+
+## 5. Pause for confirmation
+
+Ask the user for a preliminary review of the proposed changes before proceeding. If the user has feedback, address feedback and pause again for confirmation.
+
+## 6. Mandatory verification and testing
+
+Don’t finish an edit without running the linter and test suite. In DevTools, i18n placeholder changes or string edits can easily break tests or linter rules.
+
+1. **Update sibling unit tests**
+   Unit test files (`*.test.ts`) alongside the implementation often assert exact UIString values (such as error messages or warnings). When you refactor a string, check sibling `*.test.ts` files for assertions that match the old string value, and update them to prevent test failures.
+2. **Run the linter and auto-fix errors**
+   ```bash
+   npm run lint -- <folder_path>
+   ```
+3. **Run unit tests**
+   Run unit tests for the target folder first for fast feedback. Then, run the full test suite to verify that no cross-module regressions or snapshot failures occurred:
+   ```bash
+   npm run test -- <folder_path>
+   npm run test
+   ```
+4. **Run presubmit checks**
+   Ensure that you commit or stage all changes before you run presubmit checks:
+   ```bash
+   git cl presubmit -u
+   ```
+
+## 7. Summarize changes and upload the CL
+
+When all tests and presubmit checks pass, commit your changes and upload the CL to Gerrit. Don’t use `[uxw]` as a prefix.
+
+1. **Stage and commit changes**
+   ```bash
+   git add <modified_files>
+   git commit -m "Ensure consistent UI Strings in <folder_path>"
+   ```
+   *(If you update an existing commit on this branch, use `git commit --amend`).*
+
+2. **Upload the CL to Gerrit**
+   Upload the CL using `git cl upload`. Provide a dynamic summary of changes (depending on the actual content of the change) and the bug trailer:
+   ```bash
+   git cl upload -d --commit-description="Ensure consistent UI Strings in <folder_path>
+
+   Summary of changes:
+   - <dynamically list specific words replaced, contractions adopted, or sentence case fixes>
+
+   Fixed: <issue_number>"
+   ```
+   * **Formatting rules:**
+     * Keep line length below 72 characters.
+     * Include `Fixed: <issue_number>` on a separate line at the bottom of the description so that automation closes the issue.

package/.agents/skills/migrate-chromium-test/SKILL.md

@@ -1,22 +1,18 @@
 ---
 name: devtools-migrate-chromium-test
-description: Use when migrating chromium `third_party/blink/web_tests/http/tests/devtools/` tests to modern unit tests in `third_party/devtools-frontend/src/front_end/`.
+description: Use when migrating Chromium layout tests to DevTools unit tests
 ---
 
-# Migrating Legacy DevTools Tests
-
-The skill should be used from within a Chromium check out. The agent should make a devtools CL for the changes in `third_party/devtools-frontend`.
-
 ## Workflow
 
 1.  **Identify the Test to Move**:
 
-- Locate the legacy test file (usually `.js`) and its expectation file (`-expected.txt`) in `third_party/blink/web_tests/http/tests/devtools/`.
-- Example: `unit/datagrid-editable-longtext.js`
+- You should have already received the issue ID, the test title, and the exact local paths of the downloaded legacy test file (`.js`) and its expectation file (`-expected.txt`) in your initial prompt.
+- Refer to these local copies as you write the new modern test.
 
 2.  **Identify the Target Location**:
 
-- Find the file being tested in `third_party/devtools-frontend/src/front_end/`.
+- Find the file being tested in `front_end/`.
 - Place the new test file next to the file being tested, following the naming convention `[FileName].test.ts`.
 - Example: If testing `ui/legacy/components/data_grid/DataGrid.ts`, the test should be `ui/legacy/components/data_grid/DataGrid.test.ts`.
 
@@ -35,21 +31,23 @@ The skill should be used from within a Chromium check out. The agent should make
 
 5.  **Verify the Changes**:
 
-- Build the unittests target: `autoninja -C out/Default <target_path>:unittests`
-- Run the test using the DevTools test runner: `npm run test -- <relative_path_to_test>`
+- Use the `verification` skill to correctly build the project and run the new test.
 - Ensure the test passes.
 
-6.  **Clean Up**:
+6. **Evaluate Test Completeness and Utility**:
 
-- Delete the original legacy test file and its expectation file from `third_party/blink/web_tests/...`.
-- _(Optional)_ If instructed by the user, you may leave the files or handle them differently.
+- Critically review the newly created test to ensure it provides meaningful coverage. Cross-reference it with the original Chromium layout test to verify that all original behaviors, edge cases, and assertions have been fully migrated and are actively being tested.
+- If the newly added test does not test any logic from the component but just the getters from the mocked data explain to the user that this test does not add value and it's better to close it without adding the test. Provide a command without executing it to close the issue as "Fixed".
+- If the newly added test uses too extensive mocks of CDP objects and methods explain to the user that the test should be foundation e2e test instead of unit test and we won't migrate it. Provide a command without executing it to close the issue as "Won't Fix (Infeasible)".
+
+7. Upload a CL with your changes using the `version-control` skill. Make sure the CL description has a `Fixed: <issue number>` trailer instead of `Bug: <issue number>`.
 
 ## Example Conversion
 
 ### Legacy Test (`datagrid-editable-longtext.js`)
 
 ```javascript
-import { TestRunner } from 'test_runner';
+import {TestRunner} from 'test_runner';
 import * as DataGrid from 'devtools/ui/legacy/components/data_grid/data_grid.js';
 
 (async function () {
@@ -65,8 +63,8 @@ import * as DataGrid from 'devtools/ui/legacy/components/data_grid/data_grid.js'
 
 ```typescript
 import * as DataGrid from './data_grid.js';
-import { renderElementIntoDOM } from '../../../../testing/DOMHelpers.js';
-import { describeWithEnvironment } from '../../../../testing/EnvironmentHelpers.js';
+import {renderElementIntoDOM} from '../../../../testing/DOMHelpers.js';
+import {describeWithEnvironment} from '../../../../testing/EnvironmentHelpers.js';
 
 describeWithEnvironment('DataGrid', () => {
   it('tests long text in datagrid', () => {
@@ -86,59 +84,6 @@ describeWithEnvironment('DataGrid', () => {
 - **Ignoring Environment Failures**: In some environments, `npm run test` may exit with code 1 due to memory leaks (e.g., `WebFrame LEAKED`) or infrastructure issues (e.g., `gpkg` or `Corp Airlock` logs), even if the tests themselves passed. Always check the end of the test log for `TOTAL: X SUCCESS` to confirm if the test logic was successful.
 - **Rendering issue**: If you encounter an issue where checking values never gives correct information it may be due to async rendering. To resolve that you may trying using `raf()` from `front_end/testing/DOMHelpers.ts` to wait for the next rendering cycle.
 
-## Creating a DevTools CL from a Chromium Checkout
-
-To create a DevTools Change List (CL) from a Chromium checkout, you'll be working within the devtools-frontend repository, which is located inside your Chromium source tree. The depot_tools package (which includes git cl) must be in your PATH.
-
-Here's the typical workflow:
-
-1.  **Navigate to the DevTools Frontend Directory**:
-    The DevTools frontend code resides in `third_party/devtools-frontend/src/` within your Chromium checkout (`chromium/src`).
-
-```bash
-cd path/to/chromium/src/third_party/devtools-frontend/src/
-```
-
-2.  **Create a New Branch**:
-    It's best practice to create a new branch for your changes:
-
-```bash
-git new-branch my-devtools-feature
-```
-
-(Or use `git checkout -b my-devtools-feature`)
-
-3.  **Make Your Code Changes**:
-    Edit the files as needed for your feature or bug fix.
-
-4.  **Commit Changes Locally**:
-    Stage and commit your changes using standard Git commands:
-
-```bash
-git add .
-git commit -m "My DevTools feature description"
-```
-
-_See the Chromium guide on commit messages for best practices on formatting descriptions, including the use of tags like Bug:. _
-
-5.  **Upload the CL for Review**:
-    Use `git cl upload` to send your changes to the Chromium Gerrit code review system:
-
-```bash
-git cl upload
-```
-
-This command will create a CL on `https://chromium-review.googlesource.com`. Follow the prompts to add a description, reviewers, etc. You can also add reviewers and trigger builds through the Gerrit web UI.
-
-6.  **Code Review Process**:
-    Your CL will be reviewed by DevTools owners. You may need to address feedback by amending your commit and uploading new patch sets using `git cl upload` again. Once approved, you can land the change via the Commit Queue (CQ).
-
-### Working on Changes Across DevTools and Chromium Core
-
-- DevTools frontend (`third_party/devtools-frontend/src/`) and the main Chromium codebase (`chromium/src`) are distinct Git repositories.
-- If your work involves changes in both areas, you generally need to create separate CLs: one within the devtools-frontend repo and one within the main `chromium/src` repo.
-- The "Juggling the git submodules" section of the DevTools documentation provides guidance on managing these cross-repository changes.
-
 ## After finishing the migration
 
-Identify any helping tips that you discovered during the migration and add them to this skill.
+If you encountered any novel issues, workarounds, or helpful tips during the migration that are not already documented, please report them to the user so they can be added to the skill documentation.

package/.agents/skills/repro-flaky-tests/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: repro-flaky-test
+description: Reproduce and investigate flakiness in a test.
+---
+
+# Fixing flaky Tests
+
+This skill outlines the workflow for reproducing and fixing a flaky test in the DevTools codebase.
+
+## Workflow
+
+- You will be given as input, either a Chromium bug link (e.g. `crbug.com/1234567`), or a name of a test file and (optionally) the test name.
+- For example: e2e/extensions/debugger-language-plugins.test.ts and "The Debugger Language Plugins/shows sensible error messages".
+- If nothing is provided, as the user which test you should run.
+- Find the test in the codebase and look at its implementation.
+- Run the test three times to note how long the test runs (on average) per minute.
+
+## Reproduction
+
+- Run the test enough times for a full test run to take one minute. For example, if a test takes a second to run, set it to repeat 60 times. If a test takes 5 seconds to run, run it 12 times.
+- Start with one minute and, if the failure does not repeat, try again and increase the time by a minute (up to a maximum of 5 minutes per run).
+- Use `npm run test -- path/to/foo.test.ts --grep "<test name>" --repeat <count>` to run the tests repeatedly.
+- Be sure to keep track of the cumulative count of how often you run the test and how often they fail, so that you can calculate a 'flaky percentage' before and after making a fix.
+
+After every round, display the *cumulative* results in a table:
+
+```
+Test:                                                 Runs  Time   Failures
+"Recorder/should be able to start a replay..."         30    60s   0 (0.00%)
+"The Debugger Language Plugins/shows sensible..."      60    60s   1 (1.67%)
+```
+
+Once you have one or more failures, show the error message and ask the user if they want to:
+
+1) Start investigating the test failures.
+2) Continue running all the tests.
+3) Run only the failed tests (to get a clearer indication of their failure rate).
+4) Run only the tests that haven't failed (to attempt to get a reproduction).
+
+## Investigation
+
+- Create a branch flaky_tests and append a datestamp, such as _2026_07_04_14h16m.
+- Ensure you use the instructions from the `devtools-version-control` skill to create and switch branches appropriately.
+- Investigate each test failure and propose a fix.
+- Don't commit the changes to the branch.
+
+## Results
+
+- Before finishing, run the full verification process (TypeScript checks, and linters) as required by the repository best practices.
+- Request to run the test again for as long as you think it would take to be sure the problem is gone, but get permission from the user before starting very long runs (anything over 4 minutes).
+- For things that have a 33% failure rate before fixing (for example), only a handful of runs are needed to verify, but tests with lower failure rate need more.
+- NOTE: If the test fails again with the same error as before, you don't need to finish the test run but instead you should augment or replace your fix with a better one.
+- At the end, list the tests, state briefly why each test was failing and how the fix addresses the issue along with the failure rate before and after.

package/.agents/skills/ui-eng-vision-orchestrator/SKILL.md

@@ -11,7 +11,8 @@ DevTools views into declarative `UI.Widget` components based on lit-html,
 managing a multi-pass sequential CL pipeline to ensure each code modification is
 small, testable, and highly reviewable.
 
-Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general principles.
+Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general
+principles.
 
 --------------------------------------------------------------------------------
 
@@ -28,9 +29,12 @@ Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general princi
     file matches older patterns or generic examples. Always perform a structure
     analysis of the active file first and adapt the plan to the actual, current
     code.
-4.  **Hybrid Files**: Files may contain multiple classes in different states of
-    modernization (e.g., one partially migrated class and one fully legacy
-    class). Propose modifications only for classes with actual violations.
+4.  **Hybrid Files/Multiple Classes**: Files may contain multiple classes in
+    different states of modernization (e.g., one partially migrated class and
+    one fully legacy class). If the file being migrated contains several
+    classes, the migration needs to be done separately for each class, starting
+    with the leaves and going up the dependency chain. Propose modifications
+    only for classes with actual violations.
 5.  **Coupling Analysis**: Always check the integration files (e.g., sidebar
     files, parent panel files) where the target class is instantiated to see if
     there are any direct `.element` or `.contentElement` couplings. If found,
@@ -43,12 +47,21 @@ Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general princi
     single responsibility per CL. Do not combine technology migrations (e.g.,
     converting imperative DOM to Lit-html) with base class refactoring in the
     same diff.
-8.  **Never Break Compilation**: Run a compiler build and execute the DevTools
-    test suite between every pass.
+8.  **Strict Intermediate Stability**: The code must compile and work correctly,
+    and all tests must pass after each step. We should not split the class API
+    update from its usage update.
 9.  **Establish Comprehensive Guardrails First**: Ensure both **logic tests**
-    (verifying presenter interactions and state updates) and **screenshot tests**
-    (verifying layout/styling) exist before rewriting code. If coverage is
-    missing, scaffold it first.
+    (verifying presenter interactions and state updates) and **screenshot
+    tests** (verifying layout/styling) exist before rewriting code. If coverage
+    is missing, scaffold it first.
+10. **Pre-flight Clarification**: Before starting, verify if the task is
+    underspecified or ambiguous. If so, point this out and ask for
+    clarifications before proceeding.
+11. **Step Sizing & Complexity Assessment**: Assess the complexity of each step
+    beforehand. Aim for intermediate steps that involve changing or adding
+    roughly 300 lines of code. If a step is predicted to be too complex, break
+    it down into smaller substeps. The agent must stop and report back after
+    each step or substep to allow verification.
 
 --------------------------------------------------------------------------------
 
@@ -57,17 +70,22 @@ Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general princi
 ### Plan Generation (Gated)
 
 *   **Actions**:
-    1.  Scan the target file to determine size, complexity, legacy elements
+    1.  Verify if the task is underspecified or ambiguous. If so, ask for
+        clarifications first.
+    2.  Scan the target file to determine size, complexity, legacy elements
         (e.g., `ReportView`, `ToolbarButton`, `DataGrid`, `TreeOutline`), and
         actual class inheritance. Deconstruct the file mentally (or in the plan)
         into **Business Logic** (state, event handlers) and **Rendering Logic**
         (DOM creation, CSS classes). Reference code elements by **Name** (not
         line numbers) to ensure the plan remains valid as the codebase evolves.
-        Check if the class dependencies have been migrated to the ui eng vision or not.
-    2.  Check the files depending on this file, to understand how the code in
+        Check if the class dependencies have been migrated to the ui eng vision
+        or not. If the file contains multiple classes, plan the migration
+        separately for each class, starting with the leaves and going up the
+        dependency chain.
+    3.  Check the files depending on this file, to understand how the code in
         this file is being used.
-    3.  **Dynamic Ordering Decision**: Determine whether to run
-        Logic Consolidation first or Local lit-html rendering first:
+    4.  **Dynamic Ordering Decision**: Determine whether to run Logic
+        Consolidation first or Local lit-html rendering first:
         *   **Option A (Logic First)**: Choose this if the component has a
             complex, nested state model or highly coupled event-handlers.
             Consolidating the state variables and defining the `ViewInput`
@@ -78,9 +96,9 @@ Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general princi
             DOM construction. Converting the layout to declarative Lit templates
             first (using temporary inline or local state) makes it much easier
             to isolate and group the remaining state updates afterward.
-    4.  Generate a `migration_plan.md` reflecting this ordering and outlining
+    5.  Generate a `migration_plan.md` reflecting this ordering and outlining
         the target steps.
-    5.  Halt execution and print the formatted plan in Markdown to the chat.
+    6.  Halt execution and print the formatted plan in Markdown to the chat.
         Wait for user approval.
 
 ### Baseline & Safety Scaffolding
@@ -90,8 +108,9 @@ Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for general princi
 *   **Subskill to Import**: `ui-eng-vision-test-scaffolder`
 *   **Actions**:
     1.  Verify existing test coverage. Propose and add missing **logic tests**
-        for interactions and **screenshot tests** for visual validation to avoid regressions.
-    2. Pay extra attention not to skip this step.
+        for interactions and **screenshot tests** for visual validation to avoid
+        regressions.
+    2.  Pay extra attention not to skip this step.
 
 ### Logic Consolidation
 

package/.agents/skills/version-control/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: devtools-version-control
-description: Use when starting a new task, creating a branch, switching branches, managing branches, creating and uploading CLs, or handling stacked changes in the DevTools Gerrit-based workflow. ALWAYS use this instead of running standard git checkout/switch commands for branch creation.
+description: Use when starting a new task, creating a branch, switching branches, managing branches, creating and uploading CLs, handling stacked changes, or checking release and roll status in the DevTools Gerrit-based workflow. ALWAYS use this instead of running standard git checkout/switch commands for branch creation.
 ---
 
 # DevTools Version Control
@@ -73,6 +73,12 @@ To upload an updated CL:
 git cl upload -d -t "<one sentence patch set description>"
 ```
 
+## Release and Roll Status
+
+To check whether a DevTools commit (`devtools/devtools-frontend`) has rolled into `chromium/src` (`Roll status`) and what version or channel it is deployed to (`Release status`), look it up via the Chromium Dash API:
+
+`https://chromiumdash.appspot.com/fetch_commit?commit=<sha>`
+
 ## Quick Reference
 
 | Action | Command |
@@ -83,6 +89,7 @@ git cl upload -d -t "<one sentence patch set description>"
 | Upload to Gerrit | `git cl upload` |
 | Change branch parent | `git reparent-branch <new-parent>` |
 | Sync all branches | `git rebase-update` |
+| Check release & roll status | Query `https://chromiumdash.appspot.com/fetch_commit?commit=<sha>` |
 
 ## Common Mistakes
 - **Multiple commits on one branch:** Gerrit expects one commit per CL. Always `commit --amend`.

package/AUTHORS

@@ -82,6 +82,7 @@ Nourhan Hasan <nourhan.m.hasan@gmail.com>
 Paras Awasthi <awasthiparas6@gmail.com>
 Paul Fisher <paul@pfish.zone>
 Peng Zhou <zhoupeng.1996@bytedance.com>
+Percy Wang <a945970854@gmail.com>
 Per-Olov Jernberg <possan@possan.se>
 PhistucK <phistuck@gmail.com>
 Pradhuman Singh Baid <pradhumansinghbaid@gmail.com>

package/SECURITY.md

@@ -54,3 +54,6 @@ Chrome DevTools is a privileged web app running in a sandboxed renderer process,
 
 ### Side-Effect Free Evaluation
 * Side-effect free JavaScript evaluation is a best-effort developer heuristic to prevent accidental state changes, not a security boundary. Bypassing it to cause side effects on the debugged page is not a vulnerability.
+
+### Self-XSS Paste Gate
+* The self-XSS paste gate is not a security boundary. It is supposed to reduce the chance for abuse, not to fully prevent it. Issues around bypassing it are social engineering, and outside of our threat model.

package/docs/get_the_code.md

@@ -499,3 +499,9 @@ ln -s src/third_party/devtools-frontend/src devtools-frontend
 If you did run `gclient sync` first, remove the devtools-frontend directory and start over.
 
 Run `gclient sync` after creating the link to fetch the dependencies for the standalone checkout.
+
+### Known issues
+
+- GN/Siso wrappers in `depot_tools` don't assume the side-by-side solutions, and
+  always use the binaries in Chromium. Please make sure updating Chromium when
+  you get a build error.

package/front_end/Images/src/ads.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" height="20px" viewBox="0 -960 960 960" width="20px" fill="#000000"><path d="M288-384h48v-48h48v48h48v-168q0-10.2-6.9-17.1-6.9-6.9-17.1-6.9h-96q-10.2 0-17.1 6.9-6.9 6.9-6.9 17.1v168Zm48-96v-48h48v48h-48Zm192 96h96q20.4 0 34.2-13.8Q672-411.6 672-432v-96q0-20.4-13.8-34.2Q644.4-576 624-576h-96v192Zm48-48v-96h48v96h-48ZM168-192q-29.7 0-50.85-21.16Q96-234.32 96-264.04v-432.24Q96-726 117.15-747T168-768h624q29.7 0 50.85 21.16Q864-725.68 864-695.96v432.24Q864-234 842.85-213T792-192H168Zm0-72h624v-432H168v432Zm0 0v-432 432Z"/></svg>

package/front_end/Tests.js

@@ -496,8 +496,8 @@
 
   TestSuite.prototype.testConsoleOnNavigateBack = function() {
     function filteredMessages() {
-      return SDK.ConsoleModel.ConsoleModel.allMessagesUnordered().filter(
-          a => a.source !== Protocol.Log.LogEntrySource.Violation);
+      return SDK.ConsoleModel.ConsoleModel.allMessagesUnordered(SDK.TargetManager.TargetManager.instance())
+          .filter(a => a.source !== Protocol.Log.LogEntrySource.Violation);
     }
 
     if (filteredMessages().length === 1) {
@@ -710,7 +710,7 @@
     SDK.TargetManager.TargetManager.instance().addModelListener(
         SDK.ConsoleModel.ConsoleModel, SDK.ConsoleModel.Events.MessageAdded, onConsoleMessage, this);
 
-    const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered();
+    const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered(SDK.TargetManager.TargetManager.instance());
     if (messages.length) {
       const text = messages[0].messageText;
       this.assertEquals('ready', text);
@@ -976,7 +976,7 @@
   TestSuite.prototype.testWindowInitializedOnNavigateBack = function() {
     const test = this;
     test.takeControl();
-    const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered();
+    const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered(SDK.TargetManager.TargetManager.instance());
     if (messages.length === 1) {
       checkMessages();
     } else {
@@ -985,7 +985,7 @@
     }
 
     function checkMessages() {
-      const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered();
+      const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered(SDK.TargetManager.TargetManager.instance());
       test.assertEquals(1, messages.length);
       test.assertTrue(messages[0].messageText.indexOf('Uncaught') === -1);
       test.releaseControl();
@@ -1062,7 +1062,7 @@
   };
 
   TestSuite.prototype.waitForTestResultsInConsole = function() {
-    const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered();
+    const messages = SDK.ConsoleModel.ConsoleModel.allMessagesUnordered(SDK.TargetManager.TargetManager.instance());
     for (let i = 0; i < messages.length; ++i) {
       const text = messages[i].messageText;
       if (text === 'PASS') {

package/front_end/core/common/Gzip.ts

@@ -38,24 +38,31 @@ export async function fileToString(file: File): Promise<string> {
  * Consider using `arrayBufferToString` instead, which can handle both gzipped and plain text buffers.
  */
 export async function decompress(gzippedBuffer: ArrayBufferLike, charset = 'utf-8'): Promise<string> {
-  const buffer = await gzipCodec(gzippedBuffer, new DecompressionStream('gzip'));
+  const buffer = await decompressToBuffer(gzippedBuffer);
   const str = new TextDecoder(charset).decode(buffer);
   return str;
 }
 
+export async function decompressToBuffer(gzippedBuffer: ArrayBufferLike): Promise<ArrayBuffer> {
+  return await gzipCodec(gzippedBuffer, new DecompressionStream('gzip'));
+}
+
 /**
  * Decompress a deflate-encoded ArrayBuffer to a string.
  * Tries 'deflate' (zlib wrapper) first, then falls back to 'deflate-raw'.
  */
 export async function decompressDeflate(buffer: ArrayBufferLike, charset = 'utf-8'): Promise<string> {
-  let decompressedBuffer: ArrayBuffer;
+  const decompressedBuffer = await decompressDeflateToBuffer(buffer);
+  return new TextDecoder(charset).decode(decompressedBuffer);
+}
+
+export async function decompressDeflateToBuffer(buffer: ArrayBufferLike): Promise<ArrayBuffer> {
   try {
-    decompressedBuffer = await gzipCodec(buffer, new DecompressionStream('deflate'));
+    return await gzipCodec(buffer, new DecompressionStream('deflate'));
   } catch {
     // Try deflate-raw format if zlib-wrapped deflate fails.
-    decompressedBuffer = await gzipCodec(buffer, new DecompressionStream('deflate-raw'));
+    return await gzipCodec(buffer, new DecompressionStream('deflate-raw'));
   }
-  return new TextDecoder(charset).decode(decompressedBuffer);
 }
 export async function compress(str: string): Promise<ArrayBuffer> {
   const encoded = new TextEncoder().encode(str);