feat(inbox): move the selection with the arrow keys (MUL-5622) - #6269
Merged
Conversation
Up/Down inside the inbox list scrolled the container instead of walking the selection, so a notification could only be opened with the mouse. The list's scroll container now owns the arrow keys: it moves the selection by one row, scrolls the new row into view through Virtuoso (never the DOM's scrollIntoView, which also scrolls ancestors), and claims the keypress so the native scroll cannot pull the viewport off the selected row. Keyboard focus is parked on the container rather than a row, because virtualization unmounts rows as they scroll out. Scoping the handler to the container keeps Down from swapping the row out while the user is reading the issue detail. Co-authored-by: multica-agent <github@multica.ai>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
What
Arrow keys in the inbox list only scrolled the scroll container — the selection stayed put, so notifications could only be opened with the mouse. Up/Down now walk the selection like every mail-style list.
scrollIntoView, so a row that virtualization has not mounted still gets there, and a selection moving inside the viewport does not scroll at all. The DOM's ownscrollIntoViewis avoided on purpose — it scrolls every ancestor and shoves the desktop shell around ([Bug]: Small UI bug #3929).Details worth calling out:
<body>would silently kill the next keypress. Clicking a row focuses the container too — Safari does not focus a<button>on click, so without that the arrow keys would stay dead after a click.Testing
packages/views/inbox/components/inbox-list.test.tsx— 9 cases covering both directions, entering the list from either end, clamping at the ends while still claiming the key, the Virtuoso scroll call, modified arrows, text fields, IME composition, and focus after a click.pnpm exec vitest runinpackages/views— 298 files / 3474 tests pass.pnpm typecheck(repo-wide) andeslinton the touched files pass.