fix: keep the keyboard focus on the same item across a list rebuild - #1979
Open
chris-010 wants to merge 1 commit into
Open
fix: keep the keyboard focus on the same item across a list rebuild#1979chris-010 wants to merge 1 commit into
chris-010 wants to merge 1 commit into
Conversation
Tab::select_focus is an index into items_opt. Tab::set_items carries the selection over to the new list by location (item.location_opt), but the index is never recomputed, so it points at the neighbour as soon as an entry is inserted before the focused one. Creating a folder that sorts before the selected item is enough to hit it. Measured with a probe build: the selected item moved from index 1 to index 2 while select_focus stayed at 1. The first arrow-down then appears to do nothing -- it moves onto the item that is already selected -- and arrow-up afterwards looks like it skips one. The same stale index is read by select_focus_scroll, which Message::ScrollToFocused uses. That message is dispatched by TabRescan whenever selection_paths is set, i.e. right after creating an item, so the view also scrolls to the wrong row. The focused item's location is remembered before the swap and looked up again in the new list, which is exactly how the selection itself is already carried over. Drafted with AI assistance (Claude Code); the change was reviewed, built and tested by me on real hardware as described. Signed-off-by: chris-010 <10660568+chris-010@users.noreply.github.com>
chris-010
force-pushed
the
fix/keep-keyboard-focus-across-list-rebuild
branch
from
August 20, 2026 12:35
92f1bcf to
15d1f2d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Steps to reproduce
aaawill do).The first arrow-down does nothing visible, and the arrow-up after it looks like it skips an entry.
Cause
Tab::select_focusis an index intoitems_opt.set_itemscarries the selection over bylocation_optbut never recomputes that index, so it points at the neighbour once an entry is inserted before the focused one.select_focus_scrollreads the same stale index, soScrollToFocusedscrolls to the wrong row too.Fix
Remember the focused item's location before the swap and look it up again, the way the selection itself already is.
Testing
Build of
5bdfffawith only this patch: selectnnnamong six entries, createaab— ↓ then moves immediately and ↑ returns exactly one entry. In daily use here since.Rebased onto
3aa55b0since. The rebase is clean and the inserted lines are unchanged;set_items,select_focusandlocation_optare untouched by the commits in between, as are all three call sites ofset_items.cargo testpasses with no default features, with defaults, and with all features.