Fix manifest editor losing UI state on external XML edits

[Chiara Mooney (chiaramooney)]

Fixes #192

Problem

The AppxManifest visual editor lost its UI state (selected top-level tab, per-application sub-tab, expanded optional fields, and scroll position) whenever the XML was edited in the text editor.

Typing an element such as <Capability Name="internetClient" /> passes through many transiently-unparseable states. On each one, the provider reassigned webviewPanel.webview.html to swap in the parse-error page, which tears down the webview's JS context and destroys all of its state. This also explains the asymmetry the reporter noticed: editing an attribute value never breaks the XML, so state survived there.

Changes

Root cause 1 — document teardown on transient parse errors

The editor document now always loads, and every parse failure raises the same in-place overlay via a parseError message. Nothing reassigns webview.html after load, so the JS context is never torn down.

This meant picking one of the two error views, and the standalone page could not be the one that survived: it is a whole separate HTML document, so showing it is precisely the teardown that causes #192. It has been deleted (getParseErrorContent, getErrorPageStyles, and its dead retryParse handshake), along with the documentMode / errorPageMessage state machine that chose between the two views.

The overlay carries over the original's ⚠ icon, "Open in Text Editor" button, and raw parser message. The copy changed because the original's was no longer accurate — the editor does not fail to load and you do not reopen it, it recovers on its own as soon as the XML parses again:

	Deleted standalone page	Overlay
Title	"Unable to Open Manifest Editor"	"Unable to read the manifest"
Body	"...prevent the editor from loading... then reopen this editor"	"...editing is paused. Fix the XML in the text editor"

Root cause 2 — state not preserved across re-renders

• Tab, per-app sub-tab, expanded optional fields, and per-tab scroll offsets are persisted with vscode.setState() / getState() and restored on load.
• populateForm snapshots and re-applies scroll offsets around the innerHTML clears in renderApplications / renderReorderableList.
• Open dropdown menus are reopened after a background re-render, so a menu the user is about to click isn't silently closed.

Not preserved: focus and cursor position. The webview never moves focus, in either direction. The overlay does not focus itself when it appears and does not restore focus when it clears, and populateForm skips focus capture on forced (external) re-renders. Restoring focus meant calling .focus() inside the webview iframe, which yanks the caret out of the text editor mid-keystroke. Focus restoration during the webview's own edits is unchanged from main. The form behind the overlay is still inert, so keyboard and screen-reader users cannot reach paused fields.

Edit-safety guards

• Webview input is held in a shared debounce queue, discarded when the XML stops parsing or the document changes underneath it, and flushed on save — so the extension is never asked to rewrite XML it cannot parse, and queued keystrokes never replay over a newer text-editor edit.
• Extension-field inputs get per-element debounce keys, so two controls bound to the same field path no longer overwrite each other's queued keystroke.

Additional fixes

• External document changes are debounced (250 ms), so mid-word edits aren't re-rendered.
• Hiding a tab for a given package type now also clears .tab-btn.active / aria-selected, so exactly one tab button is ever marked selected.

Test harness fix

• launchVSCode now passes a dedicated --user-data-dir / --extensions-dir. Without profile isolation, the launched Code.exe forwards its arguments to any VS Code already running on the machine and exits immediately, closing Playwright's Electron handle and failing the whole suite with Target page, context or browser has been closed.

Testing

• src/test/e2e/webview-state.spec.ts (new, Chromium, 15 tests): renders the real generated webview HTML with a stubbed acquireVsCodeApi and drives the extension→webview protocol directly. Deterministic and fast (~20 s). Covers state restoration, overlay modality, the focus policy above, the debounce-discard guards, and dropdown preservation.
• src/test/e2e/external-edit-state.spec.ts (new, real VS Code, 4 tests): replays a transiently-invalid edit written to disk and asserts tab, app sub-tab, and scroll survive it; that the overlay appears in place and clears on recovery; that exactly one tab button stays active; and that saving while unparseable stores the raw text instead of rewriting the document. Verified as genuine regression coverage — 2 of 3 original tests fail without the fix. Uses its own VS Code instance because it drives on-disk edits, which conflict with the unsaved webview edits other specs leave in the shared editor.
• src/test/e2e/parse-error.spec.ts (2 tests) updated to assert the unified overlay, proving the initially-unparseable open path works end to end.
• Full E2E suite: 205 passed. The 7 failures are all pre-existing sign-quickpick tests, which CI excludes via --grep-invert; 4 further tests are known flakes. No regressions.
• npm run compile, npm run compile-tsc, npm run lint all clean (11 pre-existing curly warnings, unchanged).

Note for anyone running the E2E suite locally: npm run sync-schemas must have been run, otherwise schema validation throws before the update message is posted and the editor form never populates.

[github-actions]

VSIX Build

Artifact	Baseline	Current	Delta
VS Code Extension (VSIX)	27.88 MB	27.88 MB	📈 +2.8 KB (+0.01%)

---

Updated 2026-08-26 23:07:06 UTC · commit fb19253 · workflow run