Existing webview navigation is accepted without committing; named panel capture disagrees with workspace tabs

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

Closed bug report

John Lauer · 1mo ago ·closed by Colby Knox

Environment: adom-cli 0.5.16; Hydrogen 1.0.316, build 9ddcc472ed3ade811ae52126edd4e1fe60da871a-dirty; AdomLapper Windows host with WSL2 workspace. No Bridge verb was involved. Current local development build was preserved.

Repeated adom-cli hydrogen webview open-or-refresh --name "Depth Lab PCB" --url http://localhost:46557/ --panel-id desktop-pane-right and webview navigate --tab-id <existing-board-tab> http://localhost:46557/ returned accepted responses, but the persisted URL and actual iframe stayed on port 46556. The destination server was confirmed reachable before retrying. workspace active-tab --name "Depth Lab PCB" succeeded, but did not resolve navigation.

Exact hint: NAVIGATION_NOT_COMMITTED: navigation was ACCEPTED but the tab's persisted address still reads 'http://localhost:46556/' (requested 'http://localhost:46557/'). The hint is useful and prevented a false completion claim; please fix the underlying delivery/state mutation or return a supported actionable recovery verb.

The existing URL input was then driven through Hydrogen /eval-in using input and Enter events. This navigated the same iframe successfully, and the app reported its new renderer state. No editor pane, OS foreground or layout was changed. The screenshot shows the resulting actual webview. This narrows the failure to programmatic navigation delivery/state handling rather than destination rendering.

Related inconsistency: hydrogen screenshot panel --name "Depth Lab PCB" returned No tab matching 'Depth Lab PCB', even though workspace tabs and active-tab found that exact name. A silent shell screenshot clipped to the existing iframe succeeded. Please align tab identity resolution across navigation, activation and capture.

Expected: the existing named work-surface tab commits its new URL, paints the destination, and remains addressable by the same name. Preserve the visible VS Code pane. Root cause ownership may involve Hydrogen's event consumer; this is filed on the CLI project because these are its public commands. Issue #4 covers related opening hints, but this report is the observed navigation/capture delivery failure after those hints were added.

board-linked-camera

1 Reply

Colby Knox · 1mo ago

Shipped: adom-cli 0.5.17 (GH v0.5.17, wiki package 4.1.5). The CLI's two actionable halves, and honest framing on the third:

Supported recovery, and it is automatic. When a refresh on an existing tab is accepted but lands uncommitted (exactly your repro), open-or-refresh now recovers on its own: it removes the tab and recreates it with the same name, in the same pane, with the URL in initialState, the one programmatic path proven to commit (your /eval-in finding pointed the way; a fresh initialState is its non-interactive equivalent). The output reports action "recreated", carries the uncommitted evidence in recovered_from, and names the NEW tabId as the stable handle. --force-recreate forces that path up front, and navigate's NAVIGATION_NOT_COMMITTED block now embeds the concrete recovery command with your tab's actual name and URL. If even the recreate fails to commit, a second _commit block says so rather than claiming success. Verified live: force-recreate produces a fresh committed tab under the same name; a plain refresh is unchanged.
Capture resolution aligned. screenshot panel --name now resolves the name through the SAME find-tab route navigation and activation use, then addresses Hydrogen by tabId, so capture can no longer reject a name the workspace verbs resolve. (Hydrogen's own matcher still answers when find-tab misses, so nothing regressed for panel names that are not tabs.) Code-aligned and exercised at the resolution level; your Depth Lab repro is the real proof since the divergence lives in your Hydrogen build's matcher, so shout if capture still disagrees on 0.5.17.
The root cause stays Hydrogen's, as you suspected: an accepted navigate/refresh event that never mutates panel state is an event-delivery/state bug in Hydrogen's consumer, now the fourth item in the Hydrogen-side bundle from this pair of issues (External Webview commit, in-content persist, existing-tab delivery, name matching). The CLI now detects it, says it plainly, and recovers around it; it cannot fix the consumer. Routed to the Hydrogen owner with this issue as the evidence.

Closing since the CLI surface now behaves correctly end to end; reopen or comment if 0.5.17's recovery misses a case on your build.