chrome-devtools-frontend 1.0.1662965 → 1.0.1664619

package/.agents/skills/{creating-a-model → devtools-model-management}/SKILL.md

@@ -1,4 +1,3 @@
-```
 ---
 name: devtools-model-management
 description: Guidelines for creating, migrating, and registering models in front_end/models/. Covers BUILD.gn, devtools_grd_files.gni, and entrypoints.

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

@@ -52,7 +52,7 @@ Locate all TypeScript files in the target folder that define `const UIStrings =
    * *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.
+4. **Curly apostrophes, quotation marks, and ellipses:** Use curly apostrophes (`’`) in user-facing `UIStrings` values for contractions and possessives, 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`).
@@ -62,6 +62,7 @@ Locate all TypeScript files in the target folder that define `const UIStrings =
 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.
+   * **Straight apostrophes in comments:** Always use straight apostrophes (`'`) in code comments (such as `@description` comments and L10n annotations), even if the UI string itself uses curly apostrophes (`’`).
    * 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.
@@ -111,9 +112,9 @@ When all tests and presubmit checks pass, commit your changes and upload the CL
    *(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:
+   Upload the CL using `git cl upload -f`. Always pass `-f` (`--force`) to prevent `git cl upload` from prompting or opening an interactive text editor in background agent shells:
    ```bash
-   git cl upload -d --commit-description="Ensure consistent UI Strings in <folder_path>
+   git cl upload -f -d --commit-description="Ensure consistent UI Strings in <folder_path>
 
    Summary of changes:
    - <dynamically list specific words replaced, contractions adopted, or sentence case fixes>

package/.agents/skills/fixing-skipped-tests/SKILL.md

@@ -20,10 +20,10 @@ This skill outlines the workflow for fixing skipped tests in the DevTools codeba
    - You should look for occurrences like `it.skip('[crbug.com/<bugid>] ...', ...)` or skipped describes that mention the bug ID.
 
 4. **Iterative Fix Process**
-   - **Step 1:** Change `it.skip` or `describe.skip` to `it.only` or `describe.only` for *one* of the tests associated with the bug, so that only that specific test runs.
-   - **Step 2:** Re-run the tests (e.g., `npm run test -- <path_to_test_file>`) using the guidelines from the `devtools-verification` skill. If you are dealing with flaky tests, you can use the `--repeat=x` flag (e.g. `npm run test -- <path_to_test_file> --repeat=20`) to run the test multiple times to reproduce the flakiness.
+   - **Step 1:** Remove `it.skip` or `describe.skip` for *one* of the tests associated with the bug.
+   - **Step 2:** Re-run the specific test using its exact test ID (e.g., `npm run test path/to/foo.test.ts:test_name`) using the guidelines from the `devtools-verification` skill. If you are dealing with flaky tests, you can use the `--repeat=x` flag (e.g. `npm run test -- --repeat=20 path/to/foo.test.ts:test_name`) to run the test multiple times to reproduce the flakiness. This flag works for both E2E and unit tests.
    - **Step 3:** Analyze the test failure and make the necessary fixes to the code or the test itself.
-   - **Step 4:** Re-run the test to ensure the fix is correct. Remove `.only`.
+   - **Step 4:** Re-run the test to ensure the fix is correct.
    - **Step 5:** Remove the `[crbug.com/<bugid>]` prefix from the test name string if it is present.
    - **Step 6:** Remove any comments directly above the test that explain the reason why the test was skipped (e.g., `// TODO(crbug...): Flaky`).
    - **Step 7:** Apply the fix to the remaining tests, un-skipping them one by one or in batches, and verifying until all are passing.

package/.agents/skills/merging-devtools-module/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: devtools-module-merging
+name: merging-devtools-module
 description: Workflow for merging a DevTools submodule into its parent module. Covers BUILD.gn consolidation and updating devtools_grd_files.gni.
 ---
 

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

@@ -1,5 +1,5 @@
 ---
-name: devtools-migrate-chromium-test
+name: migrate-chromium-test
 description: Use when migrating Chromium layout tests to DevTools unit tests
 ---
 
@@ -26,6 +26,7 @@ description: Use when migrating Chromium layout tests to DevTools unit tests
 - If tests require a repetitive setup extract it into a test helper function at the top of the file.
 - Code comments must be full sentences ending with a period, except when the entire comment is a URL.
 - Do not include comments of the form `// Replaces web test: http/tests/devtools/persistence/automapping-absolute-paths.js`. Since we plan to remove migrated web tests, these are not useful references.
+- **Important** If the test imports only `TestRunner` and no other TestRunner helper or DevTools code. The test should be move to the inspector-protocol test, and the issue should be closed as "Won't Fix (Infeasible)" and add the issue to the hotlist with ID 8691563.
 
 4.  **Update BUILD.gn**:
 
@@ -40,7 +41,7 @@ description: Use when migrating Chromium layout tests to DevTools unit tests
 
 - 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)".
+- 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. **CRITICAL**  upload a comment to the issue with your investigation and the reason why you won't submit a CL and close the issue as "Won't Fix (Infeasible)" and add the issue to the hotlist with ID 8687901.
 
 7. **Upload the CL:**
 

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

@@ -1,53 +1,93 @@
 ---
-name: repro-flaky-test
+name: repro-flaky-tests
 description: Reproduce and investigate flakiness in a test.
 ---
 
-# Fixing flaky Tests
+# Workflow
 
-This skill outlines the workflow for reproducing and fixing a flaky test in the DevTools codebase.
-
-## Workflow
+This skill outlines the workflow for reproducing and fixing a flaky test in the DevTools codebase. The work should be divided into sub-agents that should only be started when certain criteria are met.
 
 - 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.
+- If nothing is provided, ask the user which test you should run.
+- Before starting the sub-agents, explain the workflow. For example:
+
+```
+I will attempt to reproduce the flakiness (simultaneously) locally and using the 'stressor bots'. Once issues are discovered, I will attempt to fix them.
+```
 
-## Reproduction
+## Reproduction agents
 
-- 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.
+First, create and start two sub-agents simultaneously. One called 'local-repro' (that should attempt to reproduce the problem locally) and one called 'bot-repro' (that attempts to use the stressor bots to reproduce).
 
-After every round, display the *cumulative* results in a table:
+### 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.
+- 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:
 
 ```
-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%)
+Test:                                                 Runs  Sec   Failures
+"Recorder/should be able to start a replay..."         30   180   0 (0.00%)
+"The Debugger Language Plugins/shows sensible..."      60   180   1 (1.67%)
 ```
 
-Once you have one or more failures, show the error message and ask the user if they want to:
+If problems were detected, list the different problems found and how often they occurred. Ask the user if the errors match the ones they are trying to get rid of.
 
-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).
+### Bot reproduction agent (bot-repro)
 
-## Investigation
+The second bot should do the following:
 
-- Create a branch flaky_tests and append a datestamp, such as _2026_07_04_14h16m.
+- Create a branch with a meaningful name, such as `deflake_<test_name>`.
 - 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.
+- Make a minor, harmless modification directly to the test file being investigated (e.g., adding a comment `// Trigger stressor bot`) to ensure the commit is not empty.
+- Add this file (with `git add`) and commit it using a meaningful commit message (e.g., `git commit -m "Deflake <test name>"`). Ask the user which bug number to use for the changelist description.
+- Upload this change using `git cl upload -f`. Always use `-f` (`--force`) so the upload runs non-interactively without opening a text editor or prompt. This creates a debugging CL that all agents (like the fix agent) will continue to work on.
+- Note the <issue number> created during upload.
+- To start the stressor bot, run this command (substituting `<test file>:exact_test_id` with the actual file and exact test ID):
+  `git cl try -B devtools-frontend/try -b e2e_stressor_linux -b e2e_stressor_win64 -b e2e_stressor_mac -p runner_args='<test file>:exact_test_id --repeat=100'`
+  - **Note on Screenshot Tests:** If the test involves screenshot assertions (`assertScreenshot`), it should ONLY be run on the Linux stressor bot (`-b e2e_stressor_linux`), because screenshot assertions are not supported on Mac or Windows. Furthermore, they cannot be reproduced locally on a Mac.
+  - **Auth Issues:** If `git cl try` fails with a login error (e.g., `Login required: run bb auth-login`), inform the user so they can resolve the auth issue and ask you to retry.
+
+- Note that the test file name needs to be relative to the root, so use `test/e2e/foo.test.ts` instead of `e2e/foo.test.ts`.
+- Check the results of the stressor tests with `git cl try-results --issue=<issue number> --patchset=<patchset number>`. You can dive into each result by id using `bb get <id>`.
+- Once a test run completes, always report to the user how often the tests ran and what the failure rate was.
+- Critical: Make sure that at least one test ran to completion on the bot (to catch incorrect syntax for `git cl try` or incorrect test IDs).
+
+## Next steps
+
+- Monitor the results of the two agents. The local reproduction bot will likely finish sooner.
+- If it does but doesn't reproduced the failure, ask the user this question:
+
+```
+While we wait for the bots to complete their run, would you like to:
+
+1) Continue trying to reproduce locally
+2) Start investigating the test
+```
+
+If they opt for investigating the test, start a new agent called 'fix-test'.
+
+### Fixing the test (fix-test)
+
+The test fixing sub-agent should do the following:
+
+- Find the test in the codebase and look at its implementation. Look at the relevant production code that is being testing.
+- Look at the failures reproduced in the test (if any) by prior sub-agents.
+- Suggest a fix for the failure(s).
+- IMPORTANT: Ensure any dummy comments added earlier to trigger the stressor bot are removed before finalizing the fix.
+- Run the full verification process (TypeScript checks, and linters) as required by the repository best practices.
+- Compile and run the test locally, to make sure there are no obvious errors introduced.
+- Commit the changes (to the branch created earlier). Make sure to list (in the changelist description) the test name, the fix, reasoning for why the test failed, why the fix fixes the issue and the failure rate (if non-zero). If you were not able to reproduce the error, state that the fix is speculative. Ask the user to provide the bug number to use in the changelist description.
+- CRITICAL: Iff the 'local-repro' bot does not reproduce the error, the 'fix-test' agent MUST wait until the stressor bot finishes its run before uploading the fix to the server (so that the stressor try run isn't aborted prematurely). If the error reproduces locally, you can upload immediately.
+- Once it is safe to do so, upload the change with `git cl upload -f`.
 
 ## 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.
+- Always verify, by running the tests again that the problem has been fixed.
+  - If the problem reproduces locally during your initially attempt, then always prefer a local reproduction run (don't use the bots).
+  - But if the problem doesn't reproduce locally, always prefer the bot-repro but run the test locally (once only per fix) to verify the fix compiles and doesn't introduce a regression..
+- For things that have (let's say) a 33% failure rate before fixing (for example), a smaller amount of run is needed to verify, than for tests with lower failure rate.
+- CRITICAL: If the test fails again with the same error as before (or a new error), it is clear that the fix is not working and a new fix must be implemented (repeat the verification cycle).
+- Upon completion, 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-widget-promoter/SKILL.md

@@ -21,6 +21,7 @@ clean `UI.Widget` classes that use native update rendering delegates.
     *   Clean up and remove older constructors that perform custom container
         initializations or access `.element` directly for manual append
         operations.
+    *   Note that `VBox` and `HBox` inherit directly from `Widget`. They fully support view injection (`view = DEFAULT_VIEW`), `performUpdate()`, and `requestUpdate()` without modification.
 
 2.  **Upgrade View Delegates & Inject View**:
 

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

@@ -60,8 +60,9 @@ git rebase-update
 ### Initial upload
 When a CL is ready, upload it with:
 ```bash
-git cl upload -d --commit-description="<description>"
+git cl upload -f -d --commit-description="<description>"
 ```
+* Always include `-f` (`--force`) so that `git cl upload` runs non-interactively without opening a text editor or prompting.
 * Use the same writing style as the current committer
 * Keep line length below 72
 * Add a "Bug: <issue number>" or "Bug: None" trailer on a separate line.
@@ -70,7 +71,7 @@ git cl upload -d --commit-description="<description>"
 ### Subsequent upload
 To upload an updated CL:
 ```bash
-git cl upload -d -t "<one sentence patch set description>"
+git cl upload -f -d -t "<one sentence patch set description>"
 ```
 
 ## Release and Roll Status
@@ -86,7 +87,7 @@ To check whether a DevTools commit (`devtools/devtools-frontend`) has rolled int
 | Create new CL from main | `git new-branch <name>` |
 | Create stacked CL | `git new-branch --upstream_current <name>` |
 | Update current CL | `git commit --amend` |
-| Upload to Gerrit | `git cl upload` |
+| Upload to Gerrit | `git cl upload -f` |
 | 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>` |

package/docs/ui_engineering.md

@@ -34,6 +34,8 @@ This approach has two main benefits:
 1.  **Testability**: In unit tests, we can pass a simple stub as the view function, which allows us to test the presenter's logic without any DOM manipulation.
 2.  **Clarity**: It cleanly separates the presenter's logic from its rendering logic.
 
+Note that `VBox` and `HBox` inherit directly from `Widget`. They fully support view injection (`view = DEFAULT_VIEW`), `performUpdate()`, and `requestUpdate()` without modification.
+
 To test the `DEFAULT_VIEW` function itself, we should use screenshot and e2e tests.
 
 ## Declarative and orchestrated DOM updates
@@ -1513,3 +1515,92 @@ The component will automatically sort and merge the ranges provided.
 
 In this example, the ranges `1,3` and `2,3` will be merged into `1,4`. The
 ranges `10,2` and the current range `5,3` will also be highlighted.
+
+## Migrating `UI.ListWidget.ListWidget`
+
+Replace the legacy imperative `UI.ListWidget.ListWidget` (which rendered inline editing controls and required custom delegates) with the modern `<devtools-list>` component.
+
+### Guidelines
+1. **Dialogue Modals for Complex Editors:** If the editor contains multiple input fields (e.g., location details, headers), show the editor in a modal card dialog powered by `UI.Dialog.Dialog`.
+2. **Inline Prompts for Trivial Editors:** If the editor is trivial (i.e., a single text input, such as URL pattern blocking rules), handle editing inline using a `<devtools-prompt>` component. In this case, clicking the item focuses the prompt and toggles `editing` mode inline, dispatching `@commit` and `@cancel` events to update the state. See `RequestConditionsDrawer` for a reference implementation.
+3. **Conditionally render list:** Use `<devtools-list>` and conditionally render it inside the card only if the list has elements (`input.locations.length > 0`). This ensures empty state layout rules are correctly applied and prevents extra spacing/gaps.
+4. **Declarative dialog views:** Define the edit/add modal content in a separate, customizable view function (e.g. `DEFAULT_DIALOG_VIEW`). Instantiating `UI.Dialog.Dialog` in the class is fine, but its content rendering should be driven declaratively by the dialog view function.
+5. **Common styles integration:** Ensure `{includeCommonStyles: true}` is passed when rendering elements into the DOM inside test setups to import proper layout variables and global typography styles (e.g. Roboto).
+
+**Before:**
+```typescript
+class SettingsTab extends UI.Widget.VBox implements UI.ListWidget.Delegate<Location> {
+  private readonly listWidget: UI.ListWidget.ListWidget<Location>;
+  constructor() {
+    super();
+    this.listWidget = new UI.ListWidget.ListWidget(this);
+    this.listWidget.show(this.element);
+  }
+
+  renderItem(item: Location, editable: boolean): Element {
+    const element = document.createElement('div');
+    element.createChild('span').textContent = item.title;
+    return element;
+  }
+
+  beginEdit(item: Location): UI.ListWidget.Editor<Location> {
+    const editor = new UI.ListWidget.Editor<Location>();
+    editor.createInput('title', 'text', 'Title', titleValidator);
+    return editor;
+  }
+
+  commitEdit(item: Location, editor: UI.ListWidget.Editor<Location>, isNew: boolean): void {
+    item.title = editor.control('title').value;
+    this.update();
+  }
+}
+```
+
+**After:**
+```typescript
+export interface SettingsTabInput {
+  items: Location[];
+  onAddClicked: () => void;
+  onEdit: (index: number) => void;
+  onDelete: (index: number) => void;
+}
+
+export const DEFAULT_VIEW: View = (input, _output, target) => {
+  render(html`
+    <devtools-card heading="Locations">
+      ${input.items.length > 0 ? html`
+        <devtools-list
+          .editable=${true}
+          .deletable=${true}
+          @edit=${(e: Lists.List.ItemEditEvent) => input.onEdit(e.detail.index)}
+          @delete=${(e: Lists.List.ItemRemoveEvent) => input.onDelete(e.detail.index)}>
+          ${input.items.map((item, index) => html`
+            <div slot="slot-${index}">
+              <span>${item.title}</span>
+            </div>
+          `)}
+        </devtools-list>
+      ` : nothing}
+      <devtools-button @click=${input.onAddClicked}>Add location</devtools-button>
+    </devtools-card>
+  `, target);
+};
+
+export interface SettingsTabDialogInput {
+  editingValues: {title: string};
+  validationErrors: {title: string | null};
+  onTitleInput: (val: string) => void;
+  onCancel: () => void;
+  onSave: () => void;
+}
+
+export const DEFAULT_DIALOG_VIEW = (input: SettingsTabDialogInput, target: HTMLElement) => {
+  render(html`
+    <div class="editor-container">
+      <input type="text" .value=${input.editingValues.title} @input=${(e: Event) => input.onTitleInput((e.target as HTMLInputElement).value)}>
+      <devtools-button @click=${input.onCancel}>Cancel</devtools-button>
+      <devtools-button @click=${input.onSave}>Save</devtools-button>
+    </div>
+  `, target);
+};
+```

package/eslint.config.mjs

@@ -621,9 +621,9 @@ export default defineConfig([
       ],
       '@devtools/l10n-i18nString-call-only-with-uistrings': 'error',
       '@devtools/l10n-no-i18nString-calls-module-instantiation': 'error',
-      '@devtools/l10n-no-locked-or-placeholder-only-phrase': 'error',
       '@devtools/l10n-no-uistrings-export': 'error',
       '@devtools/l10n-no-unused-message': 'error',
+      '@devtools/l10n-uistrings-text-style': 'error',
     },
   },
   {

package/front_end/core/common/Settings.ts

@@ -102,6 +102,8 @@ export interface SettingsCreationOptions {
   console: Console;
 }
 
+type NoFunction<T> = T extends(...args: never[]) => unknown ? never : T;
+
 export class Settings {
   readonly syncedStorage: SettingsStorage;
   readonly globalStorage: SettingsStorage;
@@ -323,6 +325,70 @@ export class Settings {
   getRegistry(): Map<string, Setting<unknown>> {
     return this.#registry;
   }
+
+  /**
+   * Resolves a setting descriptor to a concrete {@link Setting} instance.
+   *
+   * If a setting with the same name already exists (either pre-registered or
+   * previously resolved), that instance is returned. Otherwise, a new setting
+   * is created and registered.
+   *
+   * @param descriptor The descriptor defining the setting. Must not be conditional.
+   * @throws If the descriptor is conditional (contains `isAvailable`). Use `maybeResolve` instead.
+   */
+  resolve<T>(descriptor: SettingDescriptor<NoFunction<T>>&{isAvailable?: never}): Setting<T> {
+    if ('isAvailable' in descriptor) {
+      // TS can only do so much if developers downcast explicitly.
+      throw new Error('Use Settings#maybeResolve for conditional descriptors.');
+    }
+
+    return this.#resolve(descriptor);
+  }
+
+  #resolve<T>(descriptor: SettingDescriptor<T>): Setting<T> {
+    let setting = this.moduleSettings.get(descriptor.name);
+    if (setting) {
+      return setting as Setting<T>;
+    }
+
+    const {name, type, defaultValue, storageType} = descriptor;
+    const isRegex = type === SettingType.REGEX;
+
+    const isGetter =
+        (value: T|((config: Root.Runtime.HostConfig) => T)): value is((config: Root.Runtime.HostConfig) => T) =>
+            typeof value === 'function';
+
+    const evaluatedDefaultValue = isGetter(defaultValue) ? defaultValue(Root.Runtime.hostConfig) : defaultValue;
+    setting = isRegex && typeof evaluatedDefaultValue === 'string' ?
+        this.createRegExpSetting(name, evaluatedDefaultValue, undefined, storageType) :
+        this.createSetting(name, evaluatedDefaultValue, storageType);
+
+    this.registerModuleSetting(setting);
+    return setting as Setting<T>;
+  }
+
+  /**
+   * Resolves a conditional setting descriptor to a concrete {@link Setting} instance if it is available.
+   *
+   * This method checks the availability of the setting using the descriptor's `isAvailable` function
+   * and the current `hostConfig`. If available, it resolves and returns the setting (caching it if
+   * necessary). If not available (either unavailable or disabled), it returns the availability status
+   * and the reason.
+   *
+   * @param descriptor The conditional descriptor defining the setting.
+   * @returns An object with either the resolved `setting` or the availability `status` and `reason`.
+   */
+  maybeResolve<T, R>(descriptor: ConditionalSettingDescriptor<NoFunction<T>, R>): {setting: Setting<T>}|{
+    status: SettingAvailability.UNAVAILABLE|SettingAvailability.DISABLED, reason: R,
+  }
+  {
+    const available = descriptor.isAvailable(Root.Runtime.hostConfig);
+    if (available.status === SettingAvailability.AVAILABLE) {
+      return {setting: this.#resolve(descriptor)};
+    }
+
+    return available;
+  }
 }
 
 export interface SettingsBackingStore {
@@ -471,6 +537,15 @@ export class Setting<V> {
     this.#serializer = serializer;
   }
 
+  descriptor(): SettingDescriptor<V> {
+    return {
+      name: this.name,
+      type: this.type() ?? SettingType.BOOLEAN,
+      defaultValue: this.defaultValue,
+      storageType: this.#registration?.storageType,
+    };
+  }
+
   addChangeListener(listener: (arg0: EventTargetEvent<V>) => void, thisObject?: Object): EventDescriptor {
     return this.eventSupport.addEventListener(this.name, listener, thisObject);
   }

package/front_end/core/host/AidaClient.ts

@@ -64,6 +64,7 @@ const AidaLanguageToMarkdown: Record<AidaInferenceLanguage, string> = {
 export class AidaAbortError extends Error {}
 export class AidaBlockError extends Error {}
 export class AidaQuotaError extends Error {}
+export class AidaPayloadTooLargeError extends Error {}
 
 interface AiStream {
   write: (data: string) => Promise<void>;
@@ -195,13 +196,16 @@ export class AidaClient {
               return;
             }
             if ('error' in result && result.error) {
-              const errorStr = typeof result.error === 'string' ? result.error : '';
-              const detailStr = typeof result.detail === 'string' ? result.detail : '';
-              if (errorStr.toLowerCase().includes('quota') || detailStr.toLowerCase().includes('quota')) {
+              if (isQuotaError(result.error, result.detail)) {
                 stream.fail(new AidaQuotaError(
                     `Cannot send request: ${result.error}${result.detail ? ` ${result.detail}` : ''}`));
                 return;
               }
+              if (isPayloadTooLargeError(result.error, result.detail)) {
+                stream.fail(new AidaPayloadTooLargeError(
+                    `Cannot send request: ${result.error}${result.detail ? ` ${result.detail}` : ''}`));
+                return;
+              }
               stream.fail(new Error(`Cannot send request: ${result.error}${result.detail ? ` ${result.detail}` : ''}`));
               return;
             }
@@ -261,9 +265,12 @@ export class AidaClient {
             thoughtSignature: result.functionCallChunk.functionCall.thoughtSignature,
           });
         } else if ('error' in result) {
-          if (typeof result.error === 'string' && result.error.toLowerCase().includes('quota')) {
+          if (isQuotaError(result.error)) {
             throw new AidaQuotaError(`Server responded: ${JSON.stringify(result)}`);
           }
+          if (isPayloadTooLargeError(result.error)) {
+            throw new AidaPayloadTooLargeError(`Server responded: ${JSON.stringify(result)}`);
+          }
           throw new Error(`Server responded: ${JSON.stringify(result)}`);
         } else {
           throw new Error(`Unknown chunk result ${JSON.stringify(result)}`);
@@ -519,3 +526,11 @@ export const enum Events {
 export interface EventTypes {
   [Events.AIDA_AVAILABILITY_CHANGED]: void;
 }
+
+function isQuotaError(...inputs: Array<string|undefined>): boolean {
+  return inputs.some(input => input?.toLowerCase().includes('quota'));
+}
+
+function isPayloadTooLargeError(...inputs: Array<string|undefined>): boolean {
+  return inputs.some(input => input?.toLowerCase().includes('payload size exceeds the limit'));
+}

package/front_end/core/host/InspectorFrontendHostStub.ts

@@ -37,7 +37,7 @@ import {streamWrite as resourceLoaderStreamWrite} from './ResourceLoader.js';
 
 const UIStrings = {
   /**
-   * @description Document title in Inspector Frontend Host of the DevTools window
+   * @description Document title in Inspector Frontend Host of the DevTools window.
    * @example {example.com} PH1
    */
   devtoolsS: 'DevTools - {PH1}',

package/front_end/core/host/ResourceLoader.ts

@@ -12,59 +12,59 @@ import type {LoadNetworkResourceResult} from './InspectorFrontendHostAPI.js';
 
 const UIStrings = {
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   systemError: 'System error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   connectionError: 'Connection error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   certificateError: 'Certificate error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   httpError: 'HTTP error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   cacheError: 'Cache error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
-  signedExchangeError: 'Signed Exchange error',
+  signedExchangeError: '`Signed Exchange` error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   ftpError: 'FTP error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   certificateManagerError: 'Certificate manager error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   dnsResolverError: 'DNS resolver error',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   unknownError: 'Unknown error',
   /**
-   * @description Phrase used in error messages that carry a network error name
+   * @description Phrase used in error messages that carry a network error name.
    * @example {404} PH1
    * @example {net::ERR_INSUFFICIENT_RESOURCES} PH2
    */
   httpErrorStatusCodeSS: 'HTTP error: status code {PH1}, {PH2}',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
   invalidUrl: 'Invalid URL',
   /**
-   * @description Name of an error category used in error messages
+   * @description Name of an error category used in error messages.
    */
-  decodingDataUrlFailed: 'Decoding Data URL failed',
+  decodingDataUrlFailed: 'Decoding data URL failed',
 } as const;
 const str_ = i18n.i18n.registerUIStrings('core/host/ResourceLoader.ts', UIStrings);
 const i18nString = i18n.i18n.getLocalizedString.bind(undefined, str_);