chrome-devtools-frontend 1.0.1654411 → 1.0.1656897

package/.agents/skills/ui-eng-vision-local-lit-renderer/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: ui-eng-vision-local-lit-renderer
+description: Migrates legacy imperative DOM construction to local declarative Lit-html templates rendered inside existing containers.
+allowed-tools: code_search open_urls
+---
+
+# Subskill: Local Lit-HTML Renderer (Pass 2)
+
+This subskill converts consolidated imperative DOM construction helper methods
+into reactive, declarative Lit-html templates, rendering them locally inside the
+existing element containers.
+
+--------------------------------------------------------------------------------
+
+## 1. Declarative Technology Migration
+
+1.  **Conserve Abstraction Topology**:
+
+    *   Maintain the existing class hierarchy, helper class boundaries, and
+        logical groups.
+    *   Do not aggressively "flatten" classes or collapse helper abstractions
+        into the main view just to coerce a single master template. Pass 2
+        should only change the *implementation details* of rendering (imperative
+        -> declarative) within existing compartments, not the public API or
+        responsibilities of objects.
+
+2.  **Determine Render Lifecycle per Layer**:
+
+    *   **For UI.Widget classes**: Define or update `performUpdate()` to execute
+        the main lit `render` call, and use `this.requestUpdate()` to queue
+        updates.
+    *   **For Delegate/Helper classes**: Identify the custom update hook (e.g.,
+        `update()` or `scheduleUpdate()`) and invoke `render()` directly inside
+        that method. **Do not** introduce Widget lifecycle methods
+        (`performUpdate`) on classes that do not inherit them.
+
+3.  **Import Modern Templating**:
+
+    *   Import the `Lit` rendering system inside the view module:
+
+        ```typescript
+        import {html, render, nothing} from '../../ui/lit/lit.js';
+        ```
+
+4.  **Modern Component Mapping**:
+
+    *   Refer to [ui_engineering.md](../../../docs/ui_engineering.md) for
+        specific migration examples.
+    *   If unsure, also consult the [automatic migration code](../../../scripts/eslint_rules/lib/no-imperative-dom-api.ts)
+
+5.  **Local Modular Renders**:
+
+    *   If the class contains multiple separate legacy container fields (e.g.,
+        fields generated by `appendField` or `createChild` on a parent layout),
+        prefer **local modular renders** (rendering templates individually into
+        each container) to preserve the legacy layout framework. Do not force a
+        monolithic template if doing so violates the existing topology.
+
+6.  **Resolve TypeScript Type Friction**:
+
+    *   Legacy DevTools elements may be typed as `Element`. Lit's `render()`
+        function expects `HTMLElement | DocumentFragment`.
+    *   When rendering into legacy containers, cast the container using `as
+        HTMLElement` or update its class property type definition from `Element`
+        to `HTMLElement` to satisfy the TypeScript compiler.
+    *   Example: `render(this.template(), this.containerField as HTMLElement);`
+
+7.  **Delegate to Unmigrated Rendering Engines**:
+
+    *   Do not attempt to rewrite complex historical subsystems (like Linkifiers
+        or specialized UI utilities) to be "pure Lit" during this pass.
+    *   Capitalize on Lit's ability to interpolate standard `HTMLElement` or `Element` instances directly. Treat unmigrated utilities as "black boxes" that generate DOM, and embed their output in standard template expressions: `html`<div>${this.legacyElement}</div>``.
+
+8.  **Handle Asynchronous DOM Updates**:
+
+    *   For asynchronous callback-driven updates (e.g., elements updated in a
+        `.then()` callback), render the parent container or a placeholder
+        template first. Once the data is retrieved, execute a local `render()`
+        inside the callback targeting the specific sub-container.
+
+9.  **Template Factorization Strategies**:
+
+    *   **Prefer `nothing`**: Use Lit's `nothing` sentinel instead of empty
+        strings `''` or empty templates for conditional rendering.
+    *   **Parameterized Fragment Factories**: For repeated UI patterns or
+        intermediate layout branches, extract them into parameterized helper
+        functions inside the class scope returning `LitTemplate`. This avoids
+        monoliths, preserves readability, and reuses template cache strategies.
+
+10. **Visual Parity and Accessibility**:
+
+    *   **Zero-Tolerance Regression**: Screenshot tests are the ground truth for this phase. Any visual diff (above 0%) in the generated screenshots is unacceptable and must be resolved before proceeding.
+    *   **Strict Tag/Class Parity**: Do not change tag types (e.g., `span` to
+        `div`) or drop class names during template translation, as CSS may
+        depend on them.
+    *   **Explicit Component Variants**: Modern Custom Element (e.g.
+        `<devtools-button>`) defaults may not match legacy appearance.
+        Explicitly bind `.data=${{variant: Buttons.Button.Variant.OUTLINED}}`
+        (or appropriate variant) rather than relying on defaults.
+    *   **Accessibility Preservation**: Convert custom accessibility
+        instrumentation (like `ARIAUtils.markAsAlert()`) to native ARIA
+        attributes in the template (e.g., `role="alert"`, `aria-live="polite"`).
+
+11. **Render Templates Syntax & Code Movement**:
+
+    *   Surround the expressions containing lit template literals with `//
+        clang-format off` and `// clang-format on` to prevent clang-format from
+        corrupting template indentation.
+    *   **Minimize Code Movement**: Avoid moving existing code to a different location in the file. Put the function signature around the existing code to minimize the diff.
+    *   The Gerrit Code Review UI cannot identify moved blocks of unchanged code.
+    *   If blocks of code need to be reordered, create a "prefactoring" change that first extracts the code that needs to be reordered into a named helper functions and pause the migration, waiting user confirmation.
+
+12. **Wait for confirmation**:
+
+    *   Wait for an explicit confirmation from the user before proceeding to the
+        next step.

package/.agents/skills/ui-eng-vision-logic-consolidator/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: ui-eng-vision-logic-consolidator
+description: Consolidates manual DOM creation, updates, and constructors into private helper methods and structured state interfaces.
+allowed-tools: code_search open_urls
+---
+
+# Subskill: Logic Consolidator (Pass 1)
+
+This subskill extracts manual layout building, attribute modifications, and
+rendering loops out of the constructor and scattered event handlers,
+consolidating them into private helper methods with explicit data contracts.
+
+--------------------------------------------------------------------------------
+
+## 1. Logic Consolidation Rules
+
+1.  **Identify UI updates Creation**:
+
+    *   Scan the class constructor and search for manual DOM operations (e.g.,
+        `element.createChild('div')`, `document.createElement`,
+        `element.appendChild`).
+    *   Also look for any UI updates which call lit-html `render`.
+
+2.  **Isolate Update and Draw Operations**:
+
+    *   Group the imperative creation/update lines into dedicated private helper
+        methods (e.g., `#updateSummaryBar(...)` or `#createEditorToolbar(...)`).
+    *   Group event-handling updates (e.g., state variables like `pageSize`,
+        modified during buttons clicks) into centralized functions like
+        `onPageSizeChanged`.
+
+3.  **Define the State Interface**:
+
+    *   Identify the class state and ensure it is captured in the private member
+        variables, e.g.
+
+        ```typescript
+        #entries: Entry[];
+        #canGoBack: boolean;
+        #canGoForward: boolean;
+        #staleWarningVisible: boolean;
+        ```
+
+    *   Replace direct mutations of UI with updates to these member variables,
+        followed by a call to the public `performUpdate()` method that is
+        calling previously extracted update helpers. Use this specific
+        identifier.
+
+    *   If there's only one or two update helpers, consider inlining them into the
+        `performUpdate`.
+
+4.  **Extract/Consolidate Rendering Operations**:
+
+    *   If Logic First (imperative DOM remains), make sure all updates to the UI
+        go through the performUpdate method
+    *   If Lit First (Lit template already exists), make sure there's a single
+        master call to Lit render inside performUpdate. The master template
+        might include calls to the helper functions e.g.
+
+        ```typescript
+        render(html`
+          <div class="specific-view">
+            <span>View Title</span>
+            ${this.renderOverviewSection()}
+          </div>
+        `, this.contentElement);
+        ```
+
+5.  **Minimize Diffs (Safety Rule)**:
+
+    *   Avoid moving existing code to a different location in the file. Put the
+        function signature around the existing code to minimize the diff.
+    *   The Gerrit Code Review UI cannot identify moved blocks of unchanged
+        code.
+    *   If blocks of code need to be reordered, create a "prefactoring" change
+        that first extracts the code that needs to be reordered into named
+        helper functions and pause the migration, waiting for user confirmation.
+
+6.  **Wait for confirmation**:
+
+    *   Wait for an explicit confirmation from the user before proceeding to the
+        next step.

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

@@ -0,0 +1,123 @@
+---
+name: ui-eng-vision-orchestrator
+description: High-level orchestrator for managing multi-pass migration of Chrome DevTools legacy components to the modern UI engineering vision (UI.Widget & Lit-html).
+allowed-tools: code_search open_urls search_changelists data_analysis import_skill close_skill
+---
+
+# UI Engineering Vision Orchestrator: Meta-Skill Instructions
+
+This meta-skill acts as the central coordinator for modernizing legacy Chrome
+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.
+
+--------------------------------------------------------------------------------
+
+## 1. Migration Philosophy & Plan-Validate-Execute Pattern
+
+1.  **The Plan-Validate-Execute Principle**: For each target file, the
+    orchestrator must first generate a structured `migration_plan.md` listing
+    the exact transformations, file targets, and subskills allocated for each
+    pass.
+2.  **User Acceptance Gate**: The orchestrator must halt execution and present
+    the migration plan to the user. No code modification, subskill loading, or
+    CL staging can occur until the user explicitly accepts the plan.
+3.  **No Assumptions on Inheritance**: Do not assume the class hierarchy in a
+    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.
+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,
+    include the decoupling of these references in the plan.
+6.  **Neighboring Component Reference**: Inspect neighboring modernized files of
+    the same archetype (e.g., `DOMStorageItemsView.ts` or
+    `KeyValueStorageItemsView.ts` for storage-like components) to find proven
+    patterns for toolbar and data-grid configurations.
+7.  **The Narrow Bridge Principle**: Keep code modifications tightly scoped to a
+    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.
+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.
+
+--------------------------------------------------------------------------------
+
+## 2. Multi-Pass Execution Lifecycle
+
+### Plan Generation (Gated)
+
+*   **Actions**:
+    1.  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
+        this file is being used.
+    3.  **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`
+            interface first provides a clean data contract, making the
+            subsequent template conversion highly deterministic.
+        *   **Option B (Technology First)**: Choose this if the component has a
+            relatively simple state flow but massive, deeply nested imperative
+            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
+        the target steps.
+    5.  Halt execution and print the formatted plan in Markdown to the chat.
+        Wait for user approval.
+
+### Baseline & Safety Scaffolding
+
+*   **Trigger Condition**: User explicitly says "I accept the plan" or
+    equivalent.
+*   **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.
+
+### Logic Consolidation
+
+*   **Trigger Condition**: Baseline tests green (or respective previous pass
+    staged).
+*   **Subskill to Import**: `ui-eng-vision-logic-consolidator`
+*   **Actions**:
+    1.  Extract manual elements, constructor DOM configurations, and imperative
+        updates into private update helper methods with structured
+        state-passing.
+
+### Local Lit-HTML Rendering (Technology Migration)
+
+*   **Trigger Condition**: Previous pass staged.
+*   **Subskill to Import**: `ui-eng-vision-local-lit-renderer`
+*   **Actions**:
+    1.  Migrate imperative elements to declarative templates (using component
+        mapping rules defined inside the subskill) and render them locally
+        within the existing view.
+
+### Widget Promotion (Architectural Bridge)
+
+*   **Trigger Condition**: Both local template rendering and logic consolidation
+    staged.
+*   **Subskill to Import**: `ui-eng-vision-widget-promoter`
+*   **Actions**:
+    1.  Promote view classes to modern `UI.Widget` classes, hook up
+        `performUpdate()` delegates, export the default view layout, and clean
+        up legacy wrappers.

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

@@ -0,0 +1,125 @@
+---
+name: ui-eng-vision-test-scaffolder
+description: Scaffolds unit tests and screenshot tests to establish visual and functional rendering baselines for views before refactoring.
+allowed-tools: code_search open_urls
+---
+
+# Subskill: Test Scaffolder
+
+This subskill establishes the safety net of existing and new visual/functional
+tests before any codebase modifications occur, ensuring that no rendering or
+logical regressions are introduced during modernization.
+
+--------------------------------------------------------------------------------
+
+## 1. Test Verification Lifecycle
+
+1.  **Verify Existing Tests**:
+
+    *   Inspect the corresponding unit test file (e.g., `IndexedDBViews.test.ts`
+        for `IndexedDBViews.ts`) under the target folder or `test/unittests/`.
+    *   Check for **logic tests** (verifying presenter interactions and view function callbacks).
+    *   Check for screenshot or interaction tests (under `test/interactions/` or
+        `test/goldens/`) matching the visual component to verify layout and styling.
+
+2.  **Detect Sub-component Testing Gaps (Hybrid Files)**:
+
+    *   Identify if the existing test suite only covers one class of a hybrid
+        file while missing another class being migrated (e.g., tests exist for
+        `IDBDatabaseView` but are scarce/missing for `IDBDataView`).
+
+3.  **Scaffold Missing Tests**:
+
+    *   If **logic tests** are missing, draft tests verifying that callbacks trigger the expected state updates or model interactions.
+    *   If **rendering/screenshot tests** are missing or inadequate for the legacy class being
+        migrated, draft a basic Mocha/Chai rendering test.
+    *   Verify that the component compiles and mounts successfully inside a
+        synthetic DOM helper or unit-test container.
+    *   **Screenshot Tests**: Create screenshot tests to establish visual baselines before refactoring. Follow the pattern seen in `CategorizedBreakpointsSidebarPane.test.ts`:
+        *   First run the test having `renderElementIntoDOM` with `{includeCommonStyles: true}` to ensure styles are applied.
+        *   The first run will generate the screenshot.
+        *   Now try removing `{includeCommonStyles: true}` to see if class is
+            adding the styles itself. If the test pass, keep the version without
+            `{includeCommonStyles: true}`. Otherwise, bring it back.
+        *   Screenshot tests are unittests that render either the full widget (if not migrated to the MVP architecture) or its view function (if already in MVP shape).
+        *   When testing view-separated components, prefer testing the View function (e.g., `DEFAULT_VIEW`) directly by passing mock state and callbacks.
+        *   Use `assertScreenshot` to capture and verify the visual output.
+        *   Example structure:
+
+            ```typescript
+            it('renders the view', async () => {
+              const target = document.createElement('div');
+              renderElementIntoDOM(target, {includeCommonStyles: true});
+              MyComponent.DEFAULT_VIEW(mockViewInput, undefined, target);
+              await assertScreenshot('my_component/base.png');
+            });
+            ```
+
+4.  **Wait for confirmation**:
+
+    *   Wait for an explicit confirmation from the user before proceeding to the next step.
+
+--------------------------------------------------------------------------------
+
+## 2. Environment Detection & Test Execution Guide
+
+Always detect the execution environment first to run tests successfully:
+
+### Scenario A: Google-Internal Cog/Cider Workspaces (PRIMARY PATH for Google Workspaces)
+
+*   **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
+    because they lack Google cloudtop/virtualization wrapper configurations.
+*   **Resolution Steps**:
+
+    1.  Do not run `npm run test` or standard `autoninja` directly.
+    2.  Leverage the Google-specific Cider testing script to compile and run
+        tests in the cloud workspace:
+
+        ```bash
+        python3 internal/infra/scripts/cider/init_workspace.py test /google/cog/cloud/username/workspace_name --test_filter=front_end/panels/application/IndexedDBViews.test.ts
+        ```
+
+### Scenario B: Standard Chromium Environment (Fallback)
+
+*   **Detection**: Triggered if in an open-source or local standard Chromium
+    checkout without Cog paths.
+*   **Troubleshooting vpython3 / depot_tools errors**:
+
+    *   **Symptom**: Command fails with `vpython3: command not found` or
+        `python3_bin_reldir.txt not found`.
+    *   **Resolution Steps**:
+
+        1.  Export `depot_tools` path:
+
+            ```bash
+            export PATH=$PATH:/path/to/depot_tools
+            ```
+
+        2.  Initialize the depot_tools binaries by running update/gclient help
+            once from the checkout root:
+
+            ```bash
+            update_depot_tools
+            ```
+
+        3.  Execute the tests:
+
+            ```bash
+            npm run test -- front_end/panels/application/IndexedDBViews.test.ts
+            ```
+
+### Scenario C: ESLint TS Module Resolution Failure (ERR_UNKNOWN_FILE_EXTENSION)
+
+*   **Symptom**: Running lint checks fails with: `TypeError
+    [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for
+    scripts/eslint_rules/...`
+*   **Resolution Steps**:
+
+    1.  Compile the custom eslint rules and build assets first so that Node can
+        parse the rules:
+
+        ```bash
+        npm run build
+        ```

package/.agents/skills/ui-eng-vision-widget-promoter/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: ui-eng-vision-widget-promoter
+description: Promotes legacy views to modern UI.Widget classes, hooks up performUpdate() rendering, and exports default views.
+allowed-tools: code_search open_urls
+---
+
+# Subskill: Widget Promoter (Pass 3)
+
+This subskill completes the architectural transition, upgrading the component
+from legacy base classes (like `SimpleView` or custom wrapper layouts) into
+clean `UI.Widget` classes that use native update rendering delegates.
+
+--------------------------------------------------------------------------------
+
+## 1. Widget Promotion Guidelines
+
+1.  **Change Class Inheritance**:
+
+    *   Rewrite class declarations to extend `UI.Widget` (or specialized
+        sub-layouts like `UI.Widget.VBox`).
+    *   Clean up and remove older constructors that perform custom container
+        initializations or access `.element` directly for manual append
+        operations.
+
+2.  **Upgrade View Delegates & Inject View**:
+
+    *   Migrate the local Lit template strings into a formally exported default
+        view layout:
+
+        ```typescript
+        export const DEFAULT_VIEW: View = (input, output, target) => {
+          Lit.render(html`...`, target);
+        };
+        ```
+
+    *   Make the view injectable in the constructor for testability (as per `docs/ui_engineering.md`):
+
+        ```typescript
+        class MyWidget extends UI.Widget.VBox {
+          #view: View;
+          constructor(element?: HTMLElement, view: View = DEFAULT_VIEW) {
+            super(true, element);
+            this.#view = view;
+          }
+        ```
+
+    *   Implement the standard modern `performUpdate()` override on the widget:
+
+        ```typescript
+        override performUpdate(): void {
+          this.#view(this.viewInput, this.viewOutput, this.contentElement);
+        }
+        ```
+
+3.  **Clean Up Legacy Wrappers**:
+
+    *   Remove any `LegacyWrapper` bindings or custom wrappable custom elements.
+    *   Replace old panel instantiations with standard `<devtools-widget>`
+        declarative entries:
+
+        ```typescript
+        html`<devtools-widget .widgetConfig=${widgetConfig(MyWidgetClass, [params])}></devtools-widget>`
+        ```
+
+    *   Inspect instantiator files (e.g., `ApplicationPanelSidebar.ts`) and
+        decouple any direct accesses to `.element`.
+
+--------------------------------------------------------------------------------
+
+## 2. Safety & Verification Rules
+
+*   **CRITICAL**: Never update screenshot goldens without explicit consent of the user. Most likely the failure points to an issue in the implementation or (less likely) the test itself. Look at the screenshot diffs to debug.
+*   **Minimal Code Movement**: When migrating, try to move code around as little as possible, in particular around the lit rendering helpers. This minimizes the git diff and improves reviewability.
+
+--------------------------------------------------------------------------------

package/AUTHORS

@@ -49,6 +49,7 @@ Gautham Banasandra <gautham.bangalore@gmail.com>
 Han Xu <suyanhanx@gmail.com>
 Helmut Januschka <helmut@januschka.com>
 Henry Lim <henry@limhenry.xyz>
+Hojeong Park <parkhj062@gmail.com>
 Jacky Hu <flameddd@gmail.com>
 Jake Mulhern <mulherje@gmail.com>
 Jan Keitel <jan.keitel@gmail.com>

package/config/owner/COMMON_OWNERS

@@ -2,19 +2,15 @@ file://config/owner/ENG_REVIEW_OWNERS
 
 alexrudenko@chromium.org
 alinavarkki@chromium.org
-andoli@chromium.org
 bmeurer@chromium.org
-changhaohan@chromium.org
 cjamcl@chromium.org
 dsv@chromium.org
-ergunsh@chromium.org
 finnur@chromium.org
 jacktfranklin@chromium.org
 kimanh@chromium.org
 kprokopenko@chromium.org
 leese@chromium.org
 mathias@chromium.org
-nancyly@chromium.org
 nharshunova@chromium.org
 nroscino@chromium.org
 nvitkov@chromium.org

package/docs/playbook.md

@@ -36,7 +36,7 @@ For certain topics, there are dedicated points of contact (PoCs) within the DevT
 | Topic                                 | PoC             |
 | ------------------------------------- | --------------- |
 | Web Compass, Interop, and Baseline    | pfaffe@chromium.org         |
-| UI Capabilities                       | changhaohan@chromium.org    |
+| UI Capabilities                       | pfaffe@chromium.org    |
 | Performance                           | paulirish@chromium.org      |
 | JavaScript                            | szuend@chromium.org         |
 | WebAssembly                           | pfaffe@chromium.org         |

package/front_end/Tests.js

@@ -958,6 +958,7 @@
         ...Main.Main.instanceForTest.createSettingsStorage(prefs),
         settingRegistrations: Common.SettingRegistration.getRegisteredSettings(),
         runSettingsMigration: false,
+        console: Common.Console.Console.instance(),
       });
 
       const localSetting = Common.Settings.Settings.instance().createLocalSetting('local', undefined);