fix(desktop): Enter key does not send message on Windows (false IME composing guard) - #39660
Open
iborazzi wants to merge 1 commit into
Open
fix(desktop): Enter key does not send message on Windows (false IME composing guard)#39660iborazzi wants to merge 1 commit into
iborazzi wants to merge 1 commit into
Conversation
Contributor
|
Thanks for isolating the Windows Enter path. The current main handler still has the reported early return at Problems
Suggested changes
Automated hermes-sweeper review. |
iborazzi
force-pushed
the
fix/session-search-v2
branch
from
July 14, 2026 08:56
85053b4 to
ffd0c03
Compare
…on Windows Rebase the NousResearch#39649 fix onto current main and address sweeper review on NousResearch#39660: - Enter no longer submitting was only one symptom of a stuck composingRef (Chromium/Electron on Windows can fire compositionstart for plain, non-IME input and never a matching compositionend). The original PR only special-cased the keydown guard, leaving handleEditorInput and the Send-button form submit still reading the same stale ref. - handleEditorKeyDown and handleEditorInput now resync composingRef from that event's own native isComposing before deciding whether to block, so a stale true can't outlive whatever (possibly fake) composition set it, while a genuine IME composition is unaffected since isComposing is actually true for its duration. - The Send-button path has no composition event to resync from, so composingRef is cleared synchronously on blur instead — losing focus means composition, real or falsely stuck, is over either way. - Added windows-stale-composing-guard.test.tsx: false compositionstart with no compositionend still lets Enter and the Send button submit, and a genuine IME composition still blocks Enter until compositionend. Fixes NousResearch#39649
iborazzi
force-pushed
the
fix/session-search-v2
branch
from
July 14, 2026 08:56
ffd0c03 to
4351758
Compare
This was referenced Jul 28, 2026
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.
Fixes #39649
What does this PR do?
On Windows, Chromium/Electron fires
compositionstarteven for standardEnglish keyboard input, leaving
composingRef.current = truewhen theuser presses Enter. The keydown handler checked
composingRef.currentfirst and returned early, silently swallowing the Enter key.
Removing the
composingRefcheck from the keydown guard fixes this —event.nativeEvent.isComposingis sufficient and accurate across platforms.Type of Change
Changes Made
apps/desktop/src/app/chat/composer/index.tsx: removedcomposingRef.currentfrom the IME guard in
handleEditorKeyDownHow to Test
Checklist