Webview button (pup->webview swap) silently fails and resets; broker webview+pup open paths both broken on stock HD layout

by adom

See the shots your AI never showed you, and know it actually SAW them. adom-shotlog streams every screenshot the AI gathers into a live gallery (webview/pup/browser/phone), reports whether a human is really watching and on which surface, and ingests Adom Bridge child-window arrays via --meta.

Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity

Closed general

Drew Owens · 2mo ago ·edited ·closed by John Lauer

Webview button in pup viewer silently fails, then resets

Repro (Drew's laptop, 2026-07-30): viewer open in a pup window (localhost:7380/proxy/8820/log/?surface=pup&channel=nsf-pcl). Clicked the Webview button in the header. It "ran" ~30s; after switching browser tabs and returning, the button had reset to its unclicked state. No webview tab ever appeared in HD. No error shown.

Environment:

shotlog broker v0.24.3, container-side, port 8820; prefs: default_canvas=webview, webview_width=20
HD build d05e793 (dirty, Jul 24) on Windows; AD 1.9.213, target adom_drew2, connected + healthy
Viewer reached through HD's local proxy (localhost:7380/proxy/8820/...)

Root cause is almost certainly the broker's webview-open path, reproducible from the CLI:

adom-shotlog open -c nsf-pcl (webview canvas) fails with Could not find a leaf pane in workspace layout. At the same moment adom-cli hydrogen workspace get returned a layout with TWO leaf panes: desktop-pane-left (VS Code tab) and an EMPTY leaf. So the pane-finder rejects both a VS-Code-only pane (per design?) and an empty-tabs pane. Whatever the filter is, on the stock "Desktop Default" layout it finds nothing.
The empty pane's id CHURNS: it was f0eeda56-... on one workspace get and 2feeeb96-... minutes later, and a tab I added via adom-cli hydrogen workspace add-tab was silently dropped in between (HD workspace reload?). If the broker caches pane ids, the add lands 404 (Panel <id> not found, which I also reproduced).
The pup path is broken too: adom-shotlog open -c nsf-pcl --pup errors could not open the pup window (is adom-desktop connected?) even with SHOTLOG_AD_TARGET=adom_drew2 set and adom-desktop targets showing the target connected. A manual adom-desktop browser_open_window with the exact same URL worked immediately, so the broker's AD invocation is what fails, not AD.

So the Webview button click presumably hits the same server-side open/swap path as (1), fails with the leaf-pane error, and the UI never learns: the button spinner times out and state resets on next render.

Suggested quick fixes:

Pane-finder: accept an empty leaf pane as a valid target (and/or create a split when only VS Code exists); never cache pane ids across calls, re-resolve from a fresh workspace get.
Surface the failure: the button should toast the broker error instead of silently resetting.
Pup opener: log/return the underlying AD error; it is currently swallowed into the generic "is adom-desktop connected?" message even when AD is fine.

Workaround used today: manual adom-cli hydrogen workspace add-tab (tab landed in the non-rendered second pane, separate HD layout quirk) and manual browser_open_window for the pup canvas.

2 Replies

Drew Owens · 2mo ago

Addendum, same session: the problem is wider than the shotlog broker. On this HD build (d05e793-dirty, Jul 24), workspace-tab creation does not render via ANY route:

adom-cli hydrogen workspace add-tab returns ok with a tabId; the tab never appears; a later workspace get shows regenerated pane ids and the tab gone.
workspace split returns ok; the split never renders (verified with hd_shot region:full before/after: tab strip stays "VS Code" only).
HD's own control API POST /workspace/tabs (Carbon workspace proxy) returns 200 with active:true — and an immediate GET /workspace/tabs returns tabs: []. Nothing paints.

So the Webview button failure is one symptom of the workspace-tab pipeline being wedged: mutations ack but never reach the renderer. shotlog can't fix that side, but it should still surface the error instead of resetting the button.

John Lauer · 1mo ago

Fixed in 0.27.3 (adom-wiki pkg update adom/adom-shotlog). Thanks for the precise repro, it pointed straight at the cause.

What was wrong: adom-shotlog open --webview returned exit 0 even when adom-cli failed or no pane was found, so the broker reported the swap as OK and the Webview button spun for 30s and silently reset. The pane finder also assumed one workspace get envelope, and a pane id that changed between get and the add was a hard miss.

What changed:

The layout tree is located in whatever envelope workspace get uses (root, layout.root, data.root, or the bare tree), so a stock ah layout with two leaves resolves.
No pane at all is now a real failure: exit 2, with the raw workspace get output in the error so the reason is visible in the toast and the broker log.
Pane-id churn: on a "not found" the CLI re-reads the layout and retries once with the fresh id.
Any adom-cli failure exits 1 with its stdout+stderr; the Webview button now shows that text instead of resetting.
The pup path prints the bridge's actual reply on failure ("Bridge said: ..."). One thing that reply will now reveal: with more than one Adom Bridge desktop connected the bridge answers ambiguous_target, and the fix is SHOTLOG_AD_TARGET=<desktop name> in the broker's environment.

Closing; please reopen if it recurs on ah and paste the new error text.