fix(desktop): guard composer Enter during IME candidate confirmation - #40015
fix(desktop): guard composer Enter during IME candidate confirmation#400151525164075 wants to merge 1 commit into
Conversation
teknium1
left a comment
There was a problem hiding this comment.
Thanks for the focused main-composer guard.
Problems
- The same bug class remains in the current user-edit composer:
apps/desktop/src/components/assistant-ui/thread/user-edit-composer.tsx:527-577handles Enter and callssubmitEdit()without a composition/229 guard; its editor at:627-652has no composition handlers. apps/desktop/src/app/chat/composer/ime-keyboard.test.ts:7-24verifies only the pure predicate, not that a candidate-confirmation event cannot reach the production composer submit or trigger-selection paths.
Suggested changes
- Apply the shared guard to the current user-edit composer before its trigger and submit branches, and add its composition lifecycle handling.
- Add a DOM regression that proves 229/Process Enter neither submits nor selects a trigger item.
The linked #43405 discussion identifies #38794 as the canonical IME-fix cluster PR; that does not remove the live main-composer gap at apps/desktop/src/app/chat/composer/index.tsx:364-372.
Automated hermes-sweeper review.
| }) | ||
|
|
||
| it('lets the IME consume Enter for keyCode 229 candidate confirmation', () => { | ||
| expect(shouldLetImeHandleKeyDown({ key: 'Enter', keyCode: 229, isComposing: false })).toBe(true) |
There was a problem hiding this comment.
This verifies only the pure helper. Please add a DOM-level regression that drives the composer keydown path and asserts a 229/Process candidate-confirmation event cannot submit or select a trigger item.
|
This fix landed on main via #86760, which consolidated the duplicate PRs for this bug (earliest submission by @satotakumi in #37487; all contributors credited in that PR's body). Closing as the fix is now merged. Thanks for catching it! |
Summary
Test plan