Match absolute modal and nested Settings layout used by VS Code OSS

[wieslawsoltes]

Current problem

VS Code OSS 1.137 opens the real Settings UI through the Command Palette on AppScene/WebScene. The modal and surrounding Settings row cadence now match the Chromium reference closely, and 192 retained input records are accepted. The remaining demonstrated defect is the light-theme <select> principal:

• the control keeps its expected 26 px layout slot;
• the principal background and selected option text do not paint;
• the CSS pseudo-element chevron path paints, but the native control arrow path shows a missing-glyph box;
• the clipped row visible at the viewport edge was previously mistaken for collapsed row layout.

This is a WebScene form-control scene painting and hit-test defect, not a general modal/grid/layout failure and not a VS Code command-routing failure.

Exact evidence

Unchanged Code OSS revision: 645f29cc.

• Chromium capture: artifacts/release-final-next11-settings-chromium
• AppScene/WebScene capture: artifacts/release-final-next11-palette-settings-slow
• Chromium modal: [144,108,1152,724]
• Chromium Settings body: [145,142,1150,689]
• Native command/filter path: exact Settings command, font size filtered to 21 results, 192 accepted unique inputs

Required change

1. Reduce the light-theme Settings-shaped select into a browser/native contract that includes inherited foreground, native appearance, option selection, pseudo-element chevron, transforms, clipping, and pointer hit testing.
2. Trace the selected option and principal background from computed style through layout, visual creation, scene publication, and native composition.
3. Paint the selected value and background with browser-compatible clipping and stacking.
4. Use a deterministic native arrow/vector path or correctly resolved glyph; do not depend on a missing font glyph.
5. Verify pointer and keyboard selection, focus, change/input dispatch, repaint, and reload.
6. Add bounded repeated open/change/close coverage and measure recascade, layout, scene mutation/publication, CPU, and retained memory.

Acceptance

• Selected text, principal background, and arrow render in native light and dark themes.
• Geometry matches Chromium within the versioned threshold and surrounding Settings rows remain stable.
• Pointer and keyboard selection update the real unchanged Settings control and dispatch browser-shaped events.
• The reduced Chromium/native gate, WPT-derived behavior test, native regression, and hot-path performance/retention gate pass.
• The packaged Settings visual and interaction lanes pass with no VS Code source workaround.

[wieslawsoltes]

The final packaged Code OSS acceptance reopens this issue with a smaller proven generic blocker on current WebScene main 24db1a2f.

The real Cmd+Shift+P path now opens a populated palette, filters to Preferences commands, and executes Preferences: Open Settings (UI). AppScene accepted all 116 retained native input records and the Settings editor rendered, but the workbench then threw:

this.selectElement.add is not a function: TypeError

The generated native binding currently exposes only HTMLSelectElement.length and indexed option lookup. It does not expose the standard HTMLSelectElement.add(item, before) method used to populate Settings controls. This leaves Settings controls incomplete and contributes to the blank/overlapping body retained in this issue's acceptance evidence.

The focused fix will:

• add generated WebIDL-backed HTMLSelectElement.add() exposure;
• support option/optgroup append and element/index insertion with browser-shaped argument and NotFoundError behavior;
• retain the existing native tree mutation/cascade/publication path;
• add a WPT subset contract, native regression, and direct repeated-mutation performance bound;
• keep VS Code unchanged.

[wieslawsoltes]

Exact WebScene d77032df / AppScene d7cbbaf9 packaged acceptance confirms that PR #223 fixed the HTMLSelectElement.add() exception, but this issue's visual/layout acceptance is still unmet, so I am reopening it.

The real Preferences: Open Settings (UI) command now opens Settings and font size filters to 21 rendered results. Modal placement and overall geometry are correct. The remaining failure is narrower and generic:

• Chromium renders the unchanged Code OSS payload's Files: Auto Save and Editor: Default Formatter <select> controls at their normal size and preserves the following row spacing.
• WebScene omits those select controls, paints missing-glyph boxes where their controls belong, and collapses later settings rows so labels overlap at the bottom of the modal.
• Waiting for settlement does not repair the visual tree.
• The exact package otherwise passes Command Palette selection, 192/192 accepted unique native input records, Settings filtering, pointer targets, text/PNG clipboard, editor worker RPC, lifecycle, and the base editor Chromium parity gate.

Retained consumer evidence in vscode-demo:

• artifacts/release-final-next11-palette-settings-slow/settings-open.png
• artifacts/release-final-next11-palette-settings-slow/settings-filtered.png
• artifacts/release-final-next11-palette-settings-slow/summary.json
• artifacts/release-final-next11-settings-chromium/settings-open.png
• artifacts/release-final-next11-settings-chromium/settings-open-diagnostics.json

The next focused reduction should use a settings-shaped grid/list containing a labeled native <select> followed by multiple rows. It must compare Chromium and WebScene control geometry, intrinsic block contribution, paint output, and hit testing; mutate options through add(); then repeat add/remove/open/close with bounded recascade, layout, retained-tree publication, CPU, and heap gates. The fix belongs in WebScene; no VS Code workaround is acceptable.

[wieslawsoltes]

Follow-up after mapping the 2× Retina native screenshot back to CSS pixels: the later Settings row cadence is approximately correct. Auto Save → Default Formatter → Font Family advances by about 105–125 CSS px, consistent with Chromium's item rectangles at y=486.703/593.703/718.703. The text at the bottom is the next virtualized row clipped by the modal viewport, not proof of collapsed row layout.

The remaining demonstrated failure is the native <select> surface itself: its 26 px control slot appears to exist, but selected option text and the principal control paint are absent on the light background, while the arrow/pseudo content appears as a missing-glyph box. Chromium paints the complete control and selected value. The focused reduction should therefore gate select principal/text/arrow scene output and hit testing across light/dark backgrounds, with the surrounding row cadence retained as a non-regression. This narrows the prior comment; it does not change the decision to keep #112 open.

[wieslawsoltes]

Focused PR #228 merged at e13b19d10462929c2ae923b875a4c004a130e335 (authored commit 36ba9e880fefe9abc094753e643c26b51ab44405).

The root cause was narrower than principal painting: unchanged VS Code dynamically creates each Settings option with option.text = value. WebScene exposed text only on HTMLScriptElement, so HTMLOptionElement.text assignment created no text child and the existing collapsed-select painter had no selected label to paint.

The merged fix adds the standard option text binding and wrapper specialization, reusing the existing text-child replacement path. Coverage includes the Settings-shaped 320x26 select, selected value, hit ownership, hidden option boxes, following-row flow, interface/prototype behavior, normalized getter/raw child content, 4,096 additions under the performance ceiling, and bounded heap evidence.

Direct evidence:

• local native select gate: pass in 1.06 s;
• local Settings-shaped browser/native reduction: 2/2 in 82 ms;
• Native Linux document-contract run 35193182859: pass;
• package run 35193182857: webscene_native_html_select_add passed on Linux in 0.03 s and macOS in 0.02 s;
• both package jobs were red only on the known unrelated HostBridge.Services catalog check.

Broad/redundant/post-merge work was canceled. Draft consolidation #76 is refreshed through this merge at fb458c66 and remains unmerged.

This issue remains open only for the exact rebuilt Code OSS Settings visual and pointer/keyboard acceptance. No VS Code workaround was added.

[wieslawsoltes]

First-class Settings acceptance gate implemented locally

vscode-demo local integration commit 0d4733f adds the previously missing checked-in Settings visual scenario:

• opens the real upstream workbench.action.openSettings UI;
• locates files.autoSave and editor.defaultFormatter by upstream data-key;
• reads the selected label through select.options.item(select.selectedIndex).text, directly exercising the HTMLOptionElement.text contract fixed by Render labels assigned through HTMLOptionElement.text #228;
• requires exact selected value/text and non-empty option lists;
• records both setting rows and both native select rectangles;
• compares Chromium and AppScene/WebScene geometry within the versioned 2 CSS-pixel budget;
• evaluates pixel metrics inside the measured Settings editor region;
• verifies browser/native payload identity and the transient clean-profile policy;
• adds the Settings marker to fail-closed release packaging.

Validation completed before commit:

• patched VS Code 1.137 client TypeScript check: pass;
• overlay/native-probe Node tests: 16/16 pass;
• packaging/visual-parity Python tests: 44/44 pass;
• JSON/schema, Python compile, and diff checks: pass.

This does not close #112 yet. A fresh payload and final post-#148/#234 WebScene package must run the Chromium/native Settings lane, plus pointer, keyboard, persistence, and dynamic performance checks. The retained e13 package is intentionally rejected as stale by vscode-demo #2.