You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UI: sidebar (280px fixed) has no defensive overflow handling beyond .sidebar-item-title #36
The workspace-detail page uses a 280px fixed-width left sidebar (.sidebar, static/css/style.css:323) containing buttons rendered by templates/workspace.html. The chat-title row inside each item is correctly truncated with overflow: hidden; text-overflow: ellipsis; white-space: nowrap at style.css:384, but:
.sidebar-item-time (timestamp + model badge, style.css:385) has no overflow handling. A long model name with no break opportunities, or a localised date format wider than 280px, would push the sidebar item horizontally.
.sidebar itself has only overflow-y: auto; overflow-x is default visible. Any future sidebar child that doesn't inherit truncation could break out of the 280px column.
Real-world risk is low today because current timestamp + model strings fit, but the missing guard is asymmetric with how the chat-title row is treated and is easy to regress if a future PR adds a new sidebar element.
Defensive fix is a one-line CSS rule (.sidebar { overflow-x: hidden; } or per-child truncation on .sidebar-item-time), but the choice + visual review belongs in its own PR rather than bundled into a QA task.
Severity
Low · 1 point. No user-visible bug today; flagged during the issue #28 QA pass for future-proofing.
Redundant with #28 — the sidebar truncation guard landed in PR #34 alongside the QA pass (commit cc2a8f4). The original "file follow-up issues for visual bugs" rule was for bugs that wouldn't be fixed in the same PR; since this one is, no separate tracking is needed.
Activity
timon0305 commentedon May 14, 2026
Redundant with #28 — the sidebar truncation guard landed in PR #34 alongside the QA pass (commit cc2a8f4). The original "file follow-up issues for visual bugs" rule was for bugs that wouldn't be fixed in the same PR; since this one is, no separate tracking is needed.