Source: review of #41, dispositioned as tracked rather than fixed under that pull request's round bar.
Reached by: flick the mouse wheel quickly over any windowed list — Agents, the Agents table, Resources or Builds.
onMouseScroll in src/ui/widgets.tsx computes the next index from the selected prop captured at render time. When several scroll events arrive before the parent rerenders — an ordinary fast flick, batched by React into one pass — each event calculates from the same stale value, so the selection advances one row instead of the number of notches delivered.
The reader sees a list that responds sluggishly to a fast wheel and correctly to a slow one, which reads as the wheel being unreliable rather than as a batching artefact.
Fix: track the last applied selection inside the handler closure, so consecutive events accumulate until the next render.
Done when
- A test delivering several wheel events within one render advances the selection by that many rows.
- The control is the count of rows moved, not that movement occurred — a test asserting the selection changed passes on one row and proves nothing.
Why this is tracked rather than fixed in #41
#41 sits at the bottom of a five-branch stack, so any commit on it replays through four descendants. Three rounds on that pull request already came from one chain of self-introduced defects. The bar set there is that a finding is fixed only when it is a user-visible defect on a shipped path worth that cost: this one is user-visible and reachable, and its severity is a list that moves slowly rather than a wrong action or a lost value.
Context
Source: review of #41, dispositioned as tracked rather than fixed under that pull request's round bar.
Reached by: flick the mouse wheel quickly over any windowed list — Agents, the Agents table, Resources or Builds.
onMouseScrollinsrc/ui/widgets.tsxcomputes the next index from theselectedprop captured at render time. When several scroll events arrive before the parent rerenders — an ordinary fast flick, batched by React into one pass — each event calculates from the same stale value, so the selection advances one row instead of the number of notches delivered.The reader sees a list that responds sluggishly to a fast wheel and correctly to a slow one, which reads as the wheel being unreliable rather than as a batching artefact.
Fix: track the last applied selection inside the handler closure, so consecutive events accumulate until the next render.
Done when
Why this is tracked rather than fixed in #41
#41 sits at the bottom of a five-branch stack, so any commit on it replays through four descendants. Three rounds on that pull request already came from one chain of self-introduced defects. The bar set there is that a finding is fixed only when it is a user-visible defect on a shipped path worth that cost: this one is user-visible and reachable, and its severity is a list that moves slowly rather than a wrong action or a lost value.
Context
src/ui/widgets.tsx, the shared windowed list.