fix(useMouse): Magic Remote clicks dead on Chrome <51 (LG webOS 3.x)#45
Merged
Conversation
…webOS 3.x) On Chrome < 51 (LG webOS 3.x runs Chrome 38) the KeyboardEvent constructor ignores the key/keyCode/which init members, so the synthetic Enter/ArrowUp/ArrowDown events dispatched by useMouse arrived with key '' / keyCode 0 and the focusManager silently dropped them — every Magic Remote click and scroll did nothing. Detect when the constructor dropped the init members and force the values onto the event instance with Object.defineProperty getters. Modern engines keep the plain constructor path unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
What changed
useMouseroutes pointer interactions through the focus manager by dispatching syntheticKeyboardEvents —Enter(13) on click,ArrowUp/ArrowDown(38/40) on scroll wheel. On Chrome < 51 (LG webOS 3.x ships Chrome 38) theKeyboardEventconstructor exists but ignores thekey/keyCode/whichmembers ofKeyboardEventInit, so the events arrived withkey: ''/keyCode: 0. The focus manager resolves keys viakeyMapEntries[e.key] || keyMapEntries[e.keyCode], so they mapped to nothing and were silently dropped: every Magic Remote click and scroll-wheel tick did nothing on those devices. Hardware remote keys were unaffected (real events carrykeyCode).createKeyboardEventnow checks whether the constructor honored the init members and, only when it didn't, forceskey/keyCode/whichonto the event instance withObject.definePropertygetters.Why this approach
Object.getOwnPropertyDescriptor).initKeyboardEventAPI.Tests
New
describeblock intests/useMouse.test.tsx:key/keyCode/whichintact and no own-property descriptors (pure constructor path).KeyboardEventthat drops init members (mimicking Chrome 38) — the click event still reportsEnter/13/13, and withuseFocusManagerwired the element'sonEnterfires, verifying dispatch → key mapping → handler end-to-end.ArrowDown/40 andArrowUp/38 with forced values.Reviewer notes
npm run tsc, and lint all pass; no new lint warnings in touched files.🤖 Generated with Claude Code