Adom Hydrogen
Public Made by Adomby adom
The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.
Title Bar widget: "Click for the next view" does nothing; the page, view list and POST /view all check out, so the click is not reaching the iframe
The Claude usage widget's tooltip says "Click for the next view (1 of 12)". Clicking does nothing.
Environment: Hydrogen 1.0.407, widget claude-usage from adom/adom-vscode, live on port 27011, 3 meters.
I checked the widget side first, because the obvious suspicion is that the page never wired the handler up. It did, and everything on that side is correct:
- The handler exists and is bound:
document.getElementById('wrap').addEventListener('click', ...). It computesviewsFor(items), finds the current index and advances to the next. - The view list is right. With 3 items
viewsForyields exactly 12 entries:rows, threebig:N, threering:N, threeduo:i,j,nums,rings. That matches the "of 12" in the tooltip, so the page is counting the same views it offers. setViewupdates memory, writes localStorage, POSTs the choice and re-renders synchronously.- The server accepts and persists the choice. I posted a view change directly and it took, then restored the original:
before: big:0
POST /view ring:1 -> {"ok": true, "view": "ring:1"} [http 200]
after: ring:1
restored: big:0
So the page, the view list, the persistence and the server round trip all work. The link that is not working is the one I cannot test from outside the host: the click reaching the iframe at all.
The suspect
The slot only shows its tooltip on hover, and per the widget SDK hovering also raises the host's card, where "a click on the card (or its pin) pins it". A person who reads "Click for the next view" has, by definition, hovered first, so by the time they click, the card is up. If the card's layer is over the slot, their click pins the card instead of reaching the widget, and the view never changes. The Title Bar being a window drag region is the other candidate: a drag region swallows clicks from its children unless they are explicitly excluded.
Either way the fix is in the host, not in the widget page.
One loose end, reported as an observation
The stored view and the displayed view disagreed when I looked. /data.json carried view: "big:0" while the tooltip on screen read "all meters ... (1 of 12)", which is rows. Every render re-applies the server's view over the local one, so a click whose POST does not land is silently reverted on the next poll, and fetch('/view', ...) swallows its errors with .catch(() => {}). That is not the cause here, since the POST works when called directly, but a fire-and-forget write feeding a field that then overrides the user's action is worth a look while you are in there.
Related to adom/hydrogen#80: the hover card is already being reworked. If the card is what is eating the click, these two want to be solved together, and "hover shows the widget bigger" gets more useful if clicking through the views still works underneath it.