Repository navigation
[Bug]: Live sidebar updates move row action targets under the pointer #15572
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks for writing this up, @MaximilianMauroner. It's a real mis-click risk in the web sidebar, which the desktop app embeds, and it's still present on current
main. No open issue covers it. #10713, #7103, and #15418 are related but don't fix this case.What I found
- The sidebar is a live list. When a thread enters or leaves a section,
sidebarListOrderKeychanges andcreateSidebarListMotionslides the remaining rows over 150 ms (apps/web/src/components/Sidebar.motion.ts). Motion only pauses while a row is being dragged (listMotionPaused = dragState !== nullinSidebar.tsx), so hovering a row or aiming at Snooze or Settle doesn't hold the list still. - Snooze and Settle appear on hover, and each handler is tied to its own row's thread (
handleSettleClickcallsonSettle(threadRef), and snooze works the same way). After a row above appears or disappears, the control under a still pointer belongs to a different thread, and a click acts on that thread. A sweep gesture is exposed the same way, becausesidebarThreadKeyAtYreads the live layout. - fix(web): stop sidebar rows flashing and shifting on click #10713 stopped the list animating on every shell update and scrolling under a click, but real order changes still animate. fix(web): fix thread jumping after reorder #7103 was the extra jump after a manual pin reorder. fix(clients): Working section keeps its order while agents finish and wake #15418 landed after your nightly and keeps the Working section in last-user-message order, so finished runs no longer reshuffle it. Threads still shift their neighbors when one is created or leaves a visible section (settled, snoozed, archived, or returning to the inbox).
- I didn't capture a wrong-thread click in a running client, but the source path matches what you describe.
Likely fix area
apps/web/src/components/Sidebar.tsxandSidebar.motion.ts. Both ideas in the report fit: defer order changes while the pointer is over the list, or ignore a click when the thread under the pointer isn't the one it entered on. Mobile uses its own list and doesn't have this hover-action path.
A short screen recording would help with priority, though it isn't needed to confirm the mechanism. A maintainer will decide on the fix direction.
- The sidebar is a live list. When a thread enters or leaves a section,
Before submitting
Area
apps/desktop
Steps to reproduce
Reported by Max during normal use; the timing-dependent interaction has not been independently reproduced by the filing agent.
The affected action examples above are illustrative; no specific wrong-thread mutation was independently verified.
Expected behavior
Live updates should preserve the intended action target during interaction. A row changing position should not cause an action intended for one thread to apply to another.
Possible approaches include deferring row movement during interaction or canceling a click when its target changes. These are suggestions, not a prescribed implementation.
Actual behavior
Max still sees threads move when new threads arrive or existing threads leave the sidebar. This creates a risk of clicking an action on a different thread than intended.
Impact
Interaction reliability issue: live list movement can change the target of a thread action.
Version or commit
0.0.46-nightly.20261004.2644
Release commit: 7379933
Environment
T3 Code desktop on macOS.
Related work
The reported movement still occurs with those fixes present. This report concerns live insertion/removal changing action targets.
Screenshots, recordings, or supporting files
No public capture of the timing-dependent interaction is attached; the supplied screenshot shows the sidebar layout but does not demonstrate the movement.
Workaround
No verified workaround.
Opened on behalf of Max by GPT-6.1 Sol using Codex in T3 Code.