fix(dashboard/chat): show full agent name on hover in chat sidebar#5188
Conversation
Long agent names in the chat sidebar were clipped by the fixed-width list with no way to see the full text. Add a native `title` tooltip to the agent name (and provider / coordinator sub-line) so hovering a truncated row reveals the full string. The name is now resolved once into `displayName` and reused for the avatar initial, the visible label, and the tooltip, keeping the i18n fallback consistent. Truncation already used the `truncate` utility (single-line ellipsis); no layout change — purely a discoverability fix.
github-actions
Bot
added
no-rust-required
houko
left a comment
houko
left a comment
There was a problem hiding this comment.
LGTM. The fix correctly pairs the existing truncate utility on the agent name <p> with a new native title={displayName} attribute, so hover reveals the full name that the single-line ellipsis hides. Hoisting role ?? t(agents.builtin.${agent.name}.name, …) into a single displayName const and reusing it for the avatar initial, the visible label, and the tooltip removes the prior duplication without altering the i18n fallback semantics. Extending the same title treatment to the coordinator / model-provider sub-line keeps the two truncated rows consistent. The native title attribute matches the existing tooltip pattern used in ~12 places throughout ChatPage.tsx, so no new dependency or component is introduced and the sidebar layout is untouched. The decision to skip a colocated ChatPage.test.tsx is reasonable: jsdom does not exercise real overflow or hover, so a unit test would assert only that an attribute equals the resolved string and would not protect the user-visible behaviour, while standing up the first render harness for this heavy component (WebSocket / router / query-client providers) would expand the diff well beyond a one-attribute fix.
2 participants
Problem
In the chat page sidebar (
/dashboard/chat), the agent list has afixed width. When an agent's name is longer than the row, the name is
clipped with no way to see the full text — there was no
titletooltip, so a truncated name was effectively unreadable.
Fix
ChatPage.tsx→renderAgentButton:displayNameconst (keepingthe existing
role ?? t(agents.builtin.<name>.name, …)i18nfallback) and reuse it for the avatar initial, the visible label,
and a new native
titleattribute.title={displayName}to the name<p>so hovering a truncatedrow reveals the full agent name.
titletreatment to the provider / coordinatorsub-line (also
truncated) for consistency.The native
titleattribute is the dependency-free tooltip patternalready used throughout
ChatPage.tsx(12 existingtitle=usages);no new component or library is introduced. Truncation itself already
used the
truncateutility (single-line ellipsis), so this is purelya discoverability fix — no layout, sizing, or sidebar redesign.
Verification
pnpm typecheck(tsc --noEmit) — cleanpnpm build(vite) — succeeds (only the pre-existing chunk-sizeadvisory, unrelated to this change)
agent names show a single-line ellipsis and the full name appears
as a native tooltip on hover.
Scope
One file, +20/-7. No Rust changes, no route/API changes, so no
integration test is applicable.
Testing notes — why no unit test was added
ChatPagecurrently has no colocatedChatPage.test.tsx(onlylib-level
chat.test.ts/chatPicker.test.ts), unlike most pages inthis dashboard. Adding one solely for this change was judged
disproportionate:
titleattribute on atruncatedelement. The actual user-visible symptom (visual clipping / hover
tooltip rendering) is precisely what jsdom does not exercise —
no layout, no overflow, no real hover — so a test would assert only
that an attribute string equals the resolved name, restating the
one-line change rather than guarding real behaviour.
ChatPageis a heavy component (WebSocket, router, and query-clientproviders). Standing up its first render harness in jsdom is
significant setup cost for that single attribute assertion, and
would expand the diff well beyond the bug's scope.
role ?? t(agents.builtin.<name>.name, …)) is unchanged by this PR — it is merely hoisted into one constand reused — so existing behaviour is not altered in a way new
coverage would protect.
If maintainers prefer regression coverage, the lighter follow-up would
be to extract the name-resolution expression into a small pure helper
in
src/liband unit-test that in the existing style — happy to dothat in a separate PR if desired.