Closed bug report

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

Ray · 1mo ago ·closed by John Lauer

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 computes viewsFor(items), finds the current index and advances to the next.
  • The view list is right. With 3 items viewsFor yields exactly 12 entries: rows, three big:N, three ring:N, three duo:i,j, nums, rings. That matches the "of 12" in the tooltip, so the page is counting the same views it offers.
  • setView updates 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.

1 Reply

John Lauer · 1mo ago

Thanks Ray, your read of the widget side was exact and it pointed straight at the cause. The click did reach the page, and the POST landed (your before/after shows it). What went wrong was the click's own re-render: setView() re-drew from window.__last, the previous poll's copy of the data, whose view field still named the old view, and render() adopts the server's view over the local one. So the screen snapped back and the change only showed at the next poll, three minutes later. Your loose end was the bug.

Fixed in adom/adom-vscode 1.1.86: setView writes the new view into that copy before re-rendering, and a failed POST is retried once. Verified on AdomLapper with real clicks: 5h only, Fable only, 5h ring, the slot width following each. The card layer and the drag region were not it; Hydrogen 1.0.425 marks the widget strip no-drag anyway, which is harmless. Everyone gets the fix with their next package update (adom-wiki pkg update) and a widget relaunch, or on the next Hydrogen restart.

Log in to reply.