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

Activity

1. wieslawsoltes

   closed this as completedin #123on Sep 16, 2026
2. wieslawsoltes

   reopened this on Sep 17, 2026
3. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   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.
4. wieslawsoltes

   closed this as completedin #223on Sep 17, 2026
5. wieslawsoltes

   reopened this on Sep 17, 2026
6. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   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.
7. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   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.
8. wieslawsoltes commented on Sep 17, 2026

   

   wieslawsoltes

   on Sep 17, 2026

   CollaboratorAuthor

   More actions

   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.
9. wieslawsoltes

   added a parent issue on Sep 17, 2026

   • [Epic] CSS features, compatibility, validation, and performance #235
10. wieslawsoltes commented on Sep 17, 2026

    

    wieslawsoltes

    on Sep 17, 2026

    CollaboratorAuthor

    More actions

    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.
11. wieslawsoltes

    added

    vscode-oss/plannedPlanned for the AppScene/WebScene VS Code OSS integrationPlanned for the AppScene/WebScene VS Code OSS integration

    on Sep 17, 2026