Closed general

Workspace layout (webview tabs, panel splits) does not persist across ah restarts, H web parity gap

John Lauer · 1mo ago ·closed by John Lauer

Reported by Ray via gchat 2026-09-01: "all my webviews in the right panel are gone, that feels like a downgrade from H web where they always persisted." He is right, and it is structural, not a one-off.

Root cause, from the code: hd-proxy's workspace state is a process-local in-memory value and nothing ever writes it to disk or to carbon.

  • src-tauri/crates/hydrogen-proxy/src/lib.rs:38: static WORKSPACE: LazyLock<WorkspaceState> with workspace: RwLock::new(Value::Null).
  • No save/load path exists anywhere in the crate or the frontend (grepped both; the only hits are the 3D molecule layout and the dock LED memo).
  • Web Hydrogen persists the same layout server-side in carbon, which is why webview tabs survive there. ah replaced carbon's workspace API with hd-proxy but only kept the in-memory half.

So every HD restart rebuilds the default layout (VS Code + Wiki) and every webview tab the user added is silently dropped. An app update or image migration makes it look like the update ate their layout, which is exactly how Ray read it.

Proposed fix: persist the layout host-side at %APPDATA%\hydrogen-desktop\workspace-layout.json, debounced write on every layout mutation, load at proxy init. Host-side survives app updates AND image migrations (it is outside the distro). Carbon KV sync can come later for cross-machine parity; the file ends the data loss now. The existing panel-id re-resolve logic (hydrogen-proxy lib.rs:2048, "layout likely re-created after a restart") already handles stale panel ids, which is most of the restore risk.

Deliberately NOT jammed into 1.0.159 (that release is the dialog/Escape + first-run fixes); this needs its own tested change.

4 Replies

John Lauer · 1mo ago

Hydrogen 1.0.302, current build 64a449de76d762ac59fd77c3b419cafb9f78ccec-dirty (9 September 2026, 9:52 AM); Adom Bridge 2.1.83; adom-cli 0.5.15; Windows/WSL on AdomLapper.

Reproduced repeatedly during TMF8829 Depth Lab work. We restored 27 requested wiki URLs plus the live CAD tab into desktop-pane-right, then read back missing=[] and editorActive=true. A later registry read contained only the default VS Code and Wiki tabs; opening one new issue tab then produced the attached three-entry registry. This thread did not request a reset or close those tabs. App updates occurred during the work, but the exact restart/reset trigger was not captured for every occurrence.

The CAD server stayed healthy on port 45153 and restored the unchanged design revision 24. The issue is loss of workspace layout, not loss of the project's saved CAD state. It disrupts the user's browser-led engineering workflow and previously interrupted a recording. Tabs being present once and a healthy SSE endpoint are insufficient persistence evidence.

Please verify a persisted layout across the actual installed-app update/restart path, including a live app tab, authenticated wiki pages, active tab per pane, stable destination outside VS Code, and the user's pane sizes. A source patch or fresh default workspace should not count as that test. Current mitigation is a task-owned URL manifest and paced, read-back-verified restore; it does not fix persistence.

cad-workspace-reset-tabs.json

cad-hydrogen-buildinfo.json

Ray · 1mo ago

Another symptom of the same root cause, from Ray on ROG-Zephyrus, 2026-09-10 (gchat):

  • the sidebar hidden state does not persist
  • after closing the sidebar, the previous pane widths are not restored
  • so the workspace layout has to be rebuilt by hand each time

This issue's diagnosis covers webview tabs and panel splits, but sidebar visibility and pane widths live in the same process-local WORKSPACE value (hydrogen-proxy/src/lib.rs:38), so the persistence path proposed here would cover them too. Recording them here rather than opening a second issue, so the fix is scoped to all of it at once.

One correction worth making to the title's scope: Ray is hitting this on refresh, not only on an ah restart. That is a much lower bar than "across restarts" suggests, and it is why it reads as a daily papercut rather than an occasional one: a refresh is something a user does many times a day, and each one costs a full layout rebuild.

John Lauer · 1mo ago

Triaged with John today: fix now, and it becomes a joint feature with Project Workspaces (1.0.385), which already captures a live layout as a workspace file and rebuilds one from it. The restart path uses the same code: on every layout change ah writes the current tree, sidebar state and pane widths to a file under the profile, per logged-in user, and on start it applies that file the way a bench is applied. Signing in as a different user gets an independent layout. A "Reset to default layout" entry in the Project workspaces menu brings the stock layout back for anyone who has painted themselves into a corner. Nothing goes to Carbon (cloud key-value size limits), so cross-box sync is not part of this.

John Lauer · 1mo ago

Shipped, verified, closing. Hydrogen 1.0.388 through 1.0.390 (the three builds are one feature; the second and third fixed what testing caught).

What it does: the live pane tree (webview tabs, splits, sidebar state, pane widths) is saved to a per-user file under the profile on every change, coalesced so an apply that adds several tabs writes once, and restored the first time the editor reads it after a restart. It is keyed by the Adom user id from the profile cache, so signing in as a different person gets an independent layout. Local only, no Carbon, per John's call on the key/value size limits. It reuses the Project workspaces tree format, so a saved layout and a bench are the same shape.

Reset: "Reset to default layout" in the Project workspaces menu, POST /workspaces/reset on the control API, and POST .../current/reset on the proxy clear the saved layout and reload the editor so it builds its stock panes.

Proof on arav-rog: added a marker webview tab, confirmed it landed in layouts/user-.json, restarted Hydrogen through the control API, and the marker tab was back after the restart with the log line "restored saved layout ... user-6738b00a...json". Then the reset route returned the panes to VS Code plus Wiki.

What testing caught, for the record: 1.0.388 saved correctly but lost the restore race (the editor built and pushed its default before the proxy's lazy restore could run), so 1.0.389 restores at proxy startup and has the editor adopt the proxy's tree before building any default. 1.0.390 made the reset reload the editor, because a cleared tree alone left the panes empty.

Ray, your sidebar state and pane widths ride in the same tree, so they come back too.

Log in to reply.