chrome-devtools-frontend 1.0.1716465 → 1.0.1717196

package/.agents/skills/devtools-model-management/SKILL.md

@@ -9,7 +9,7 @@ This guide outlines the standard procedure for creating a new model or migrating
 
 ## 0. Preparation (Before you start)
 *   **Baseline:** Run existing tests for the code you are moving to ensure they pass *before* you touch anything.
-    *   `npm run test -- front_end/<old_location>`
+    *   `./dt test front_end/<old_location>`
 *   **Impact Analysis:** Search for usages of the class/file to understand the scope of refactoring.
     *   `grep -r "ClassName" front_end/`
 
@@ -44,10 +44,10 @@ The build system does not auto-detect new modules. You must manually register th
 
 ## 5. Verification Checklist
 1.  **Build:** `autoninja -C out/Default` (Ensures BUILD.gn and GRD files are correct).
-2.  **Lint:** `npm run lint` (Checks style and formatting).
+2.  **Lint:** `./dt lint` (Checks style and formatting).
 3.  **Test:**
-    *   `npm run test -- front_end/models/<model_name>` (New tests).
-    *   `npm run test -- front_end/<old_location>` (Regression check for previous owner).
+    *   `./dt test front_end/models/<model_name>` (New tests).
+    *   `./dt test front_end/<old_location>` (Regression check for previous owner).
 
 ## Common Pitfalls
 *   **Circular Dependencies:** Occur when internal files import from the directory's own barrel file.

package/.agents/skills/devtools-setting-migration/SKILL.md

@@ -144,7 +144,7 @@ const setting = Common.Settings.Settings.instance().resolve(preserveConsoleLogSe
 
 ### Step 6: Verify Changes
 1. Run `autoninja -C out/Default` to check GN build.
-2. Run `npm run lint` to check style and formatting rules.
+2. Run `./dt lint` to check style and formatting rules.
 3. Run relevant unit tests for the modified module.
 
 ---

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

@@ -10,10 +10,9 @@ Use this skill when addressing a single UX writing refactoring task (one module
 
 ## 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:
+In DevTools Linux workspaces, `depot_tools` may not be in `PATH` in non-interactive agent shells. Before you run Git, `gclient`, `./dt`, 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
@@ -103,14 +102,14 @@ Don’t finish an edit without running the linter and test suite. In DevTools, i
    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>
+   ./dt lint <folder_path>
    ```
 3. **Run unit tests**
-   You MUST run the full test suite using `npm run test` to verify that no cross-module regressions, e2e test failures, or snapshot regressions occurred. Do not only run a subset of tests:
+   You MUST run the full test suite using `./dt test` to verify that no cross-module regressions, e2e test failures, or snapshot regressions occurred. Do not only run a subset of tests:
    ```bash
-   npm run test
+   ./dt test
    ```
-   *(Optionally, you may run `npm run test -- <folder_path>` first for rapid initial feedback during iterative development, but running `npm run test` for full test suite coverage is required before completing the task.)*
+   *(Optionally, you may run `./dt test <folder_path>` first for rapid initial feedback during iterative development, but running `./dt test` for full test suite coverage is required before completing the task.)*
 4. **Run presubmit checks**
    Ensure that you commit or stage all changes before you run presubmit checks:
    ```bash

package/.agents/skills/devtools-verification/SKILL.md

@@ -1,15 +1,19 @@
 ---
 name: devtools-verification
-description: "MANDATORY: Activate this skill ANY TIME you need to build the project, run tests, or verify code health in DevTools. You MUST use this skill before executing commands like npm test, npm run build, autoninja, or linters, as it contains critical, repository-specific instructions on how to correctly format these commands, filter test runs, and interpret failures."
+description: "MANDATORY: Activate this skill ANY TIME you need to build the project, run tests, or verify code health in DevTools. You MUST use this skill before executing commands like ./dt test, ./dt build, autoninja, or linters (never run these through npm or npx), as it contains critical, repository-specific instructions on how to correctly format these commands, filter test runs, and interpret failures."
 ---
 
 # Instructions on how to verify your changes
 
+## Running scripts
+
+Run the scripts from the root `package.json` (`test`, `lint`, `build`, `start`, and so on) with `./dt <script> [args]` from the repository root (on Windows: `.\dt <script> [args]`). Don't use `npm run`, `npm test`, or `npx` for them. Run `./dt` without arguments to list the available scripts. Arguments after the script name are passed to the script as is, so don't add a `--` separator.
+
 ## Testing
 
-- To test a file, you can run `npm run test -- <FILEPATH>` where `FILEPATH` is a path to a `*.test.ts` file, relative to the working directory.
+- To test a file, you can run `./dt test <FILEPATH>` where `FILEPATH` is a path to a `*.test.ts` file, relative to the working directory.
 - Test files are usually defined alongside their implementation. So if you are working on `front_end/panels/timeline/TimelinePanel.ts`, you would expect the test file to be defined in `front_end/panels/timeline/TimelinePanel.test.ts`.
-- You can also test an entire directory. For example, `npm run test -- front_end/models/trace` will run all tests in that directory.
+- You can also test an entire directory. For example, `./dt test front_end/models/trace` will run all tests in that directory.
 
 ## Building & compiling
 
@@ -17,8 +21,8 @@ description: "MANDATORY: Activate this skill ANY TIME you need to build the proj
 
 ## Linting
 
-- `npm run lint` will execute ESLint and StyleLint. It will report any violations and automatically fix them where possible.
-- To run the linter on a specific file or directory, you can run `npm run lint -- <PATH>` where `PATH` is a path to a file or directory. This will also automatically fix violations where possible.
+- `./dt lint` will execute ESLint and StyleLint. It will report any violations and automatically fix them where possible.
+- To run the linter on a specific file or directory, you can run `./dt lint <PATH>` where `PATH` is a path to a file or directory. This will also automatically fix violations where possible.
 
 ## Fetching Tryjob Results, Failure Logs, & Screenshot Goldens
 

package/.agents/skills/fix-tests/SKILL.md

@@ -22,7 +22,7 @@ First, create and start two sub-agents simultaneously. One called 'local-repro'
 
 ### Local reproduction (local-repro)
 
-- Use command: `npm run test -- --repeat=<count> path/to/foo.test.ts:exact_test_id` to locally run the tests repeatedly. Both E2E and unit tests support this. Use the exact test ID printed in the test runner output (usually the suite and test names with spaces replaced by underscores). Do not use `--grep` or a `bash` script with a `for` loop.
+- Use command: `./dt test --repeat=<count> path/to/foo.test.ts:exact_test_id` to locally run the tests repeatedly. Both E2E and unit tests support this. Use the exact test ID printed in the test runner output (usually the suite and test names with spaces replaced by underscores). Do not use `--grep` or a `bash` script with a `for` loop.
 - First run the test three times to note how long the test runs (on average).
 - Then run the test continuously for 4 minutes, while noting any failures and failure rates. If the failure rate is still 0% after that, assume the problem does not reproduce locally.
 - After the local test run completes, then show the results in a table. For example:

package/.agents/skills/foundation-test-migration/SKILL.md

@@ -162,10 +162,10 @@ Foundation tests must pass in both Node.js and Browser runtimes.
 
 ### Run in Node.js
 ```bash
-npm test -- front_end/core/sdk/NetworkManager.test.ts --node-unit-tests
+./dt test front_end/core/sdk/NetworkManager.test.ts --node-unit-tests
 ```
 
 ### Run in Browser
 ```bash
-npm test -- front_end/core/sdk/NetworkManager.test.ts
+./dt test front_end/core/sdk/NetworkManager.test.ts
 ```

package/.agents/skills/ui-eng-vision-test-scaffolder/SKILL.md

@@ -69,11 +69,11 @@ Always detect the execution environment first to run tests successfully:
 
 *   **Detection**: Triggered if the workspace path starts with `/google/cog/` or
     `/google/src/`.
-*   **Why it is required**: Raw commands like `npm run test` or `autoninja` fail
+*   **Why it is required**: Raw commands like `./dt test` or `autoninja` fail
     because they lack Google cloudtop/virtualization wrapper configurations.
 *   **Resolution Steps**:
 
-    1.  Do not run `npm run test` or standard `autoninja` directly.
+    1.  Do not run `./dt test` or standard `autoninja` directly.
     2.  Leverage the Google-specific Cider testing script to compile and run
         tests in the cloud workspace:
 
@@ -107,7 +107,7 @@ Always detect the execution environment first to run tests successfully:
         3.  Execute the tests:
 
             ```bash
-            npm run test -- front_end/panels/application/IndexedDBViews.test.ts
+            ./dt test front_end/panels/application/IndexedDBViews.test.ts
             ```
 
 ### Scenario C: ESLint TS Module Resolution Failure (ERR_UNKNOWN_FILE_EXTENSION)
@@ -121,7 +121,7 @@ Always detect the execution environment first to run tests successfully:
         parse the rules:
 
         ```bash
-        npm run build
+        ./dt build
         ```
 
 ### Scenario D: Screenshot Test Fails (Visual Diffs > 0%)
@@ -141,4 +141,3 @@ Always detect the execution environment first to run tests successfully:
 1.  ❓ **Coverage**: Did I cover all classes in the file, or only the main one?
 2.  ❓ **Stability**: Can the tests run repeatedly without flakiness?
 3.  ❓ **Integrations**: Did I verify that the component mounts correctly?
-

package/docs/README.md

@@ -71,7 +71,7 @@ below.**
 
 Formats all code using clang-format.
 
-`npm test`
+`./dt test`
 
 Runs all tests on DevTools code.
 

package/docs/contributing/README.md

@@ -157,9 +157,9 @@ be accepted.
 If your patch is finished, we have a few helpful tools to make sure your patch looks good.
 
 As part of the presubmit check, we will automatically run these. You can also run specific
-presubmit checks by using our `npm` commands:
+presubmit checks by using our `./dt` commands:
 
-*   `npm run lint` to perform [ESLint](http://eslint.org) and [Stylelint](http://stylelint.io)
+*   `./dt lint` to perform [ESLint](http://eslint.org) and [Stylelint](http://stylelint.io)
     checks.
 
 To run these presubmit checks without uploading, you can run `git cl presubmit --upload`.
@@ -252,7 +252,7 @@ If reviewers will ask you to change something in your code, follow these steps:
 2. Run `gsync client`.
 3. Optionally, pull latest changes and rebase them with: `git pull --rebase origin main`.
 4. Commit locally to your branch.
-5. Run the linters on your code (e.g. style, coding conventions) via `npm run lint`.
+5. Run the linters on your code (e.g. style, coding conventions) via `./dt lint`.
 6. Finally, upload everything to the server again with `git cl upload`.
 7. Once complete, add a comment similar to "comments addressed, please take a look".
    Without a comment, reviewers will not know about your new patchset.

package/docs/cookbook/dependencies.md

@@ -59,7 +59,7 @@ Chromium licensing to be used, on the basis that it enforces all packages have a
 license that is compatible with a set of pre-defined licensees.
 
 If you want to use a new package as tooling process in engineer workflows, you
-can add the package to the `package.json` and run `npm run install-deps` to
+can add the package to the `package.json` and run `./dt install-deps` to
 check in the new contents.
 
 Only add new license types to `LICENSES` after you received approval from

package/docs/get_the_code.md

@@ -27,9 +27,18 @@ To build, follow these steps:
 ```bash
 cd devtools-frontend
 gclient sync
-npm run build
+./dt build
 ```
 
+Scripts from `package.json` are run with `./dt <script> [args]` (on Windows:
+`.\dt <script> [args]`), a launcher for `scripts/tools/dt.py`. Run it without arguments
+to list the available scripts. Arguments after the script name are passed to the script
+as is, so no `--` is needed.
+
+`npm run <script> -- [args]` works too if you have npm installed, e.g.
+`npm run test -- foo` is the same as `./dt test foo`. AI agents should use `./dt`, not
+`npm run`.
+
 The resulting build artifacts can be found in `out/Default/gen/front_end`.
 
 The build tools generally assume `Default` as the target (and `out/Default` as the
@@ -37,7 +46,7 @@ build directory). You can pass `-t <name>` (or `--target=<name>`) to use a diffe
 target. For example
 
 ```bash
-npm run build -- -t Debug
+./dt build -t Debug
 ```
 
 will build in `out/Debug` instead of `out/Default`. If the directory doesn't exist,
@@ -51,14 +60,14 @@ to `false`:
 gn gen out/Fast --args="devtools_bundle=false"
 ```
 
-and use `npm run build -- -t Fast` to build this target.
+and use `./dt build -t Fast` to build this target.
 
 ### Rebuilding automatically
 
 You can use
 
 ```bash
-npm run build -- --watch
+./dt build --watch
 ```
 
 to have the build script watch for changes in source files and automatically trigger
@@ -96,7 +105,7 @@ if you encounter any errors.
 
 ### Using a `.env` file for default script options
 
-Many scripts, like `npm run build` and `npm start`, accept command-line flags to configure their behavior (e.g., `-t <target>`, `--browser=<name>`).
+Many scripts, like `build` and `start`, accept command-line flags to configure their behavior (e.g., `-t <target>`, `--browser=<name>`).
 
 To avoid typing these flags every time, you can set your preferred defaults in a .env file at the root of the devtools-frontend directory.
 
@@ -106,13 +115,13 @@ The `.env.template` file lists all supported variables. Copy it to `.env` to get
 cp .env.template .env
 ```
 
-As mentioned earlier, you might create a fast build target. Instead of always typing `npm run build -- -t Fast`, to remove the flag repetition you simple run `npm run build` you can set the following variable in your `.env` file:
+As mentioned earlier, you might create a fast build target. Instead of always typing `./dt build -t Fast`, to remove the flag repetition you simple run `./dt build` you can set the following variable in your `.env` file:
 
 ```shell
 DEVTOOLS_TARGET=Fast
 ```
 
-Another example - by default running `npm start` auto-opens DevTools for new Tabs.
+Another example - by default running `./dt start` auto-opens DevTools for new Tabs.
 You may want to disable this so fewer pop-up happen while debugging, usually done via `--no-open` flag. Or with `.env` set the following value:
 
 ```shell
@@ -154,43 +163,43 @@ You can run a [build](#Build) of DevTools frontend in a pre-built Chrome or Chro
 - Use the downloaded Chrome for Testing binary in `third_party/chrome`.
 - Use the latest Chrome Canary. This includes any DevTools features that are only available in regular Chrome builds (`is_official_build` + `is_chrome_branded`), such as GenAI-related features.
 
-#### Using `npm start` script (recommended)
+#### Using the `start` script (recommended)
 
 With Chromium 136, we added (back) a `start` script that can be used to easily launch DevTools with pre-built [Chrome
 for Testing](https://developer.chrome.com/blog/chrome-for-testing) or [Chrome Canary](https://www.google.com/chrome/canary/).
 It'll also take care of automatically enabling/disabling experimental features that are actively being worked on. Use
 
 ```bash
-npm start
+./dt start
 ```
 
 to build DevTools front-end in `out/Default` (you can change this to `out/foo` by passing `--target=foo` if needed),
 and open Chrome for Testing (in `third_party/chrome`) with the custom DevTools front-end. This will also monitor the
 source files for changes while Chrome is running and automatically trigger a rebuild whenever source files change.
 
-By default, `npm start` will automatically open DevTools for every new tab, you can use
+By default, `./dt start` will automatically open DevTools for every new tab, you can use
 
 ```bash
-npm start -- --no-open
+./dt start --no-open
 ```
 
 to disable this behavior. You can also use
 
 ```bash
-npm start -- --browser=canary
+./dt start --browser=canary
 ```
 
 to run in Chrome Canary instead of Chrome for Testing; this requires you to install Chrome Canary manually first
 (Googlers can install `google-chrome-canary` on gLinux). And finally use
 
 ```bash
-npm start -- http://www.example.com
+./dt start http://www.example.com
 ```
 
 to automatically open `http://www.example.com` in the newly spawned Chrome tab. Use
 
 ```bash
-npm start -- --verbose
+./dt start --verbose
 ```
 
 to enable verbose logging, which among other things, also prints all output from Chrome to the terminal, which is
@@ -198,38 +207,38 @@ otherwise suppressed.
 
 ##### Controlling the feature set
 
-By default `npm start` will enable a bunch of experimental features (related to DevTools) that are considered ready for teamfood.
+By default `./dt start` will enable a bunch of experimental features (related to DevTools) that are considered ready for teamfood.
 To also enable experimental features that aren't yet considered sufficiently stable to enable them by default for the team, run:
 
 ```bash
 # Long version
-npm start -- --unstable-features
+./dt start --unstable-features
 
 # Short version
-npm start -- -u
+./dt start -u
 ```
 
 Just like with Chrome itself, you can also control the set of enabled and disabled features using
 
 ```bash
-npm start -- --enable-features=DevToolsWellKnown
-npm start -- --disable-features=DevToolsWellKnown --enable-features=DevToolsFreestyler:multimodal/true
+./dt start --enable-features=DevToolsWellKnown
+./dt start --disable-features=DevToolsWellKnown --enable-features=DevToolsFreestyler:multimodal/true
 ```
 
 which you can use to override the default feature set.
 
 ##### Remote debugging
 
-The `npm start` command also supports launching Chrome for remote debugging via
+The `./dt start` command also supports launching Chrome for remote debugging via
 
 ```bash
-npm start -- --remote-debugging-port=9222
+./dt start --remote-debugging-port=9222
 ```
 
 or
 
 ```bash
-npm start -- --browser=canary --remote-debugging-port=9222 --user-data-dir=\`mktemp -d`
+./dt start --browser=canary --remote-debugging-port=9222 --user-data-dir=\`mktemp -d`
 ```
 
 Note that you have to also pass the `--user-data-dir` and point it to a non-standard profile directory (a freshly created
@@ -362,22 +371,22 @@ out/Default/chrome --custom-devtools-frontend=file://$(realpath out/Default/gen/
 afterwards, which can be quite a bit faster than building and linking the full
 Chromium binary.
 
-Alternatively you can use `npm start` from the DevTools sub folder (`third_party/devtools-frontend/src/`) with the browser set to `chromium`.
+Alternatively you can use `./dt start` from the DevTools sub folder (`third_party/devtools-frontend/src/`) with the browser set to `chromium`.
 This will tell the command that you are in a Chromium checkout and try to find the correct browser executable path to resolve.
 Or alternately you can use a `.env` file, see [set up here](#using-a-env-file-for-default-script-options).
 
 ```bash
 cd third_party/devtools-frontend/src/
-npm start -- --browser=chromium
+./dt start --browser=chromium
 ```
 
 ### Testing
 
-To run the test suite, use `npm test` from within the DevTools front-end folder:
+To run the test suite, use `./dt test` from within the DevTools front-end folder:
 
 ```bash
 cd third_party/devtools-frontend/src
-npm test
+./dt test
 ```
 
 ### Juggling the git submodules

package/dt

@@ -0,0 +1,7 @@
+#!/bin/sh
+# Copyright 2026 The Chromium Authors
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+#
+# Launcher for scripts/tools/dt.py, so it can be run as `./dt <script> [args]`.
+exec vpython3 "$(dirname "$0")/scripts/tools/dt.py" "$@"

package/dt.bat

@@ -0,0 +1,8 @@
+@echo off
+rem Copyright 2026 The Chromium Authors
+rem Use of this source code is governed by a BSD-style license that can be
+rem found in the LICENSE file.
+rem
+rem Launcher for scripts\tools\dt.py, so it can be run as `dt <script> [args]`.
+call vpython3 "%~dp0scripts\tools\dt.py" %*
+exit /b %ERRORLEVEL%

package/front_end/core/common/ParsedURL.ts

@@ -334,7 +334,7 @@ export class ParsedURL {
     // 8 - ?fragment
     const schemeRegex = /([A-Za-z][A-Za-z0-9+.-]*):\/\//;
     const userRegex = /(?:([A-Za-z0-9\-._~%!$&'()*+,;=:]*)@)?/;
-    const hostRegex = /((?:\[::\d?\])|(?:[^\s\/:]*))/;
+    const hostRegex = /((?:\[[0-9a-fA-F:.]*:[0-9a-fA-F:.]*\])|(?:[^\s\/:]*))/;
     const portRegex = /(?::([\d]+))?/;
     const pathRegex = /(\/[^#?]*)?/;
     const queryRegex = /(?:\?([^#]*))?/;