Repository navigation
[lexical-react][lexical-playground] Bug Fix: Keep the arrow key highlight when a typeahead menu scrolls under the mouse - #9391
Open
Thanatos9404 wants to merge 1 commit into
Conversation
…ight when a typeahead menu scrolls under the mouse ## Description Pressing ArrowDown or ArrowUp in a typeahead menu scrolls the highlighted option into view. With the mouse resting over the menu, the scroll slides another option under it, the browser fires mouseenter there, and the highlight jumps back to it. The default menu now moves the highlight on mousemove, and only when the pointer position has changed, because WebKit also fires a mousemove after the scroll at the position the pointer never left. If the arrow keys come first, the first mousemove only records the position. Taps still highlight and select, since touch sends a mousemove before the click. Wheel scrolling and typing a filter no longer move the highlight until the mouse moves. The playground's `li:hover` style is removed so that only the highlighted row is grey. Menus with their own `menuRenderFn` are unchanged. Closes meta#4296 ## Test plan ### Before ``` $ pnpm exec vitest --project unit --no-watch packages/lexical-react/src/__tests__/unit/LexicalMenu.test.tsx × keeps the keyboard highlight when the list scrolls under a still pointer × keeps the ArrowDown highlight when the menu opened under a still pointer × keeps the ArrowUp highlight when the menu opened under a still pointer AssertionError: expected 2 to be 1 // Object.is equality AssertionError: expected 2 to be 1 // Object.is equality AssertionError: expected 1 to be 2 // Object.is equality Tests 3 failed | 19 passed (22) ``` In the playground, resting the mouse on the third "/" option and pressing ArrowDown ten times (local Playwright script, highlighted index after each press): ``` chromium 153.0.8010.12: 3, 4, 5, 3, 4, 5, 6, 4, 5, 6 firefox 155.0: 3, 4, 5, 3, 4, 5, 6, 4, 5, 6 webkit 26.6: 3, 4, 5, 3, 4, 5, 6, 4, 5, 6 ``` ### After ``` $ pnpm exec vitest --project unit --no-watch packages/lexical-react/src/__tests__/unit/LexicalMenu.test.tsx Tests 22 passed (22) $ pnpm exec vitest --project unit --no-watch packages/lexical-react packages/lexical-playground Test Files 74 passed (74) Tests 674 passed (674) ``` ``` chromium 153.0.8010.12: 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 firefox 155.0: 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 webkit 26.6: 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 ``` With mousemove but no position check, WebKit still jumped (3, 4, 2, 3, 4, 5, 3, 4, 5, 6). When the menu opens under a mouse that never moves, the highlight also follows the keys (1 to 10 in all three). Moving the mouse still highlights the option under it, and clicking an option without moving or tapping one with touch emulation still inserts it. `tsc`, `tsc-test`, `flow full-check` (0 errors), and `eslint` and `prettier --list-different` on the changed files pass. The ComponentPicker, Mentions and DraggableBlock e2e specs pass in Chromium; the Firefox and WebKit failures I saw there also fail or flake on `main`. All of this ran on Windows with Node 24.21.0, so WebKit is Playwright's Windows build rather than Safari, and touch was only emulated.
Thanatos9404
requested review from
acywatson,
etrepum,
fantactuka,
ivailop7,
potatowagon and
zurfyx
as code owners
October 20, 2026 07:51
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
lexical
@lexical/a11y
@lexical/clipboard
@lexical/code
@lexical/code-core
@lexical/code-prism
@lexical/code-shiki
@lexical/compiler
@lexical/devtools-core
@lexical/dragon
@lexical/eslint-plugin
@lexical/extension
@lexical/fast-check
@lexical/file
@lexical/hashtag
@lexical/headless
@lexical/history
@lexical/html
@lexical/internal
@lexical/link
@lexical/list
@lexical/mark
@lexical/markdown
@lexical/mdast
@lexical/offset
@lexical/overflow
@lexical/plain-text
@lexical/react
@lexical/rich-text
@lexical/selection
@lexical/table
@lexical/tailwind
@lexical/text
@lexical/utils
@lexical/yjs
commit: |
![rootnode-bot[bot]](https://avatars.githubusercontent.com/in/5614656?s=60&v=4){kind=small}
There was a problem hiding this comment.
This looks good, thanks! Tracking down WebKit's same-position mousemove is what makes the position check necessary rather than a plain switch to onMouseMove. Rerunning your scenario (pointer resting on the third / option, ArrowDown ten times) in Chromium, Firefox and WebKit reproduces the jump on main and shows the highlight advancing one option per press with this change, and the new unit tests fail without the fix and pass with it.
Two optional, non-blocking suggestions:
- A browser-level regression test. The new cases in
packages/lexical-react/src/__tests__/unit/LexicalMenu.test.tsxrun on jsdom with hand-built event sequences, so they pin the handler logic but not the browser behavior that triggers the bug. AGENTS.md (Testing Strategy) puts real input and layout in browser-mode or e2e tests; a case inpackages/lexical-playground/__tests__/e2e/ComponentPicker.spec.mjsthat hovers the third option, presses ArrowDown five times and asserts that the eighth option has.selectedfails onmainand would keep this fixed. - A line in the description about the hover change. In the default menu, hover highlighting now needs pointer movement, and the first move after an arrow key only records the position (
packages/lexical-react/src/shared/LexicalMenu.tsx:355-367). People using a mouse won't notice, but app test suites will: a syntheticmouseover/mouseenteralone no longer highlights an option, and a single-step Playwrighthover()after ArrowDown leaves the keyboard highlight in place. AGENTS.md (Backwards Compatibility) asks us to assume external code depends on current behavior, so calling this out helps app authors who drive the menu from tests.
This branch was successfully deployed
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
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.
Description
Pressing ArrowDown or ArrowUp in a typeahead menu scrolls the highlighted option into view. With the mouse resting over the menu, the scroll slides another option under it, the browser fires mouseenter there, and the highlight jumps back to it.
The default menu now moves the highlight on mousemove, and only when the pointer position has changed, because WebKit also fires a mousemove after the scroll at the position the pointer never left. If the arrow keys come first, the first mousemove only records the position. Taps still highlight and select, since touch sends a mousemove before the click. Wheel scrolling and typing a filter no longer move the highlight until the mouse moves. The playground's
li:hoverstyle is removed so that only the highlighted row is grey. Menus with their ownmenuRenderFnare unchanged.Closes #4296
Test plan
Before
In the playground, resting the mouse on the third "/" option and pressing ArrowDown ten times (local Playwright script, highlighted index after each press):
After
With mousemove but no position check, WebKit still jumped (3, 4, 2, 3, 4, 5, 3, 4, 5, 6). When the menu opens under a mouse that never moves, the highlight also follows the keys (1 to 10 in all three). Moving the mouse still highlights the option under it, and clicking an option without moving or tapping one with touch emulation still inserts it.
tsc,tsc-test,flow full-check(0 errors), andeslintandprettier --list-differenton the changed files pass. The ComponentPicker, Mentions and DraggableBlock e2e specs pass in Chromium; the Firefox and WebKit failures I saw there also fail or flake onmain. All of this ran on Windows with Node 24.21.0, so WebKit is Playwright's Windows build rather than Safari, and touch was only emulated.