Halt a running glide before a landing that finds the pane already in place

[ben-dev-au]

Problem

• Down then Up in the results list, with the second press landing before the first glide had moved the pane, left the preview on the first target (the table) while the cursor sat on the section above it.
• Cause: a match landing scrolls with Textual's scroll_to_region, which measures from the pane's live position and issues nothing on a zero delta. Textual stops a running scroll animation only inside _scroll_to, which a zero-delta call never reaches, so the earlier glide ran on.
• A scroll trace of a failing run: the second landing's scroll_to_region(y=65) is followed by no scroll call, while the first landing's was followed by scroll_relative and scroll_to.

Fix

• MatchAwareScroll.halt_glide() drops a running scroll_y animation where it is: animating to the current value makes Textual pop it, which avoids force_stop_animation's jump to the old target. It also resets scroll_target_y, which Reading View's j/k step from.
• The match landing (StructuralScrollStrategy._scroll_pane_to_match_region) and the n/b stop scroll (MatchNavigator._scroll_to_stop) call it first.
• On a non-zero delta the landing ends at the same row as before. It now glides from where the pane was halted; main painted a one-frame jump to the old glide's end first.

Tests

• New, test_a_scroll_to_where_the_pane_already_is_still_ends_a_glide[landing|nb_stop]: main fails it 3 of 3 (assert 0 == 52), this branch passes 3 of 3.
• Down then Up under the test harness, 7 gaps from 30 to 150 ms with 4 runs each: main mislanded 2 of 4 at 50 ms, this branch 0 of 28.
• make batch-close: ruff, pyright, 4916 passed / 3 skipped, tmux harness green.
• Reviewed adversarially: no blocker.

Known limits

• A live terminal did not reproduce the bug on main in 83 tries (gaps 0 to 120 ms, and both keys in one input burst). There the glide has usually moved before the second landing is computed, so this fixes a real defect at the Textual level rather than an observed live symptom.
• A glide that has been committed but not yet started is not halted. An animated landing's _scroll_to is queued with call_after_refresh, so for 1 to 17 ms it is neither running nor scheduled, and halt_glide sees nothing to stop. The review confirmed this at a seam that starts the first glide the production way, but could not trigger it from key presses. Closing it means MatchAwareScroll dropping a stale queued scroll when a new landing arrives, which changes deferred-scroll behaviour for every caller, so it is left out of this change.
• Dropping the animation skips its on_complete, so Textual's _realtime_animation_count gains one per halt. That count only gates PAUSE_GC_ON_SCROLL, which is off and never set in fnd.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: c566c525-bc6c-4874-8b45-dc8ec04725ae

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}