Open bug report

Title bar widgets: two widgets on one port show the wrong widget; same id from a checkout shows both as open

John Lauer · 5d ago

Seen on a Windows Hydrogen (public 1.0.703 era), title bar widget picker.

1. Opening Antigravity usage showed the AI Flow progress widget

adom/antigravity and adom/adom-aiflow both declared launch.port 27020. AI Flow's widget server was already on 27020, so Antigravity's server could not bind, and the slot framed whatever answered on the port: AI Flow's page, under the Antigravity entry. The picker reported Antigravity as open.

Unblocked now: adom/antigravity 0.2.9 moves to 27021. But nothing stops the next collision:

  • Hydrogen should confirm the server on the port is the widget it launched before framing it (for example a /hydrogen-widget identity answer with the id, or at least that the launch did not fail to bind), and otherwise show "port 27020 is held by another program" in the slot.
  • The curated list (adom/hydrogen-bootstrap widgets/widgets.json) and widget publish should refuse a port another curated widget already declares.

Ports today: 27011, 27012, 27014 (adom-vscode), 27013 (clock), 27020 (adom-aiflow), 27021 (antigravity).

2. A checkout and a published widget with the same id both show "Close"

src/lib/components/editor/TitleBarWidgets.svelte:233 decides Open or Close with $openWidgetIds.includes(w.id), and slots resolve with $widgets.find((x) => x.id === id). A checkout (local/widget-ref) carrying claude-usage and codex-usage, the same ids as adom/adom-vscode, makes both rows read "Close" for the one widget actually open, and the slot uses whichever copy is first in the list.

Fix: key open widgets by wiki_repo + '/' + id (the {#each} key already does), and launch and resolve by that key.

0 Replies

Log in to reply.