Skip to content

fix(desktop): Enter key does not send message on Windows (false IME composing guard) - #39660

Open
iborazzi wants to merge 1 commit into
NousResearch:mainfrom
iborazzi:fix/session-search-v2
Open

fix(desktop): Enter key does not send message on Windows (false IME composing guard)#39660
iborazzi wants to merge 1 commit into
NousResearch:mainfrom
iborazzi:fix/session-search-v2

Conversation

@iborazzi

@iborazzi iborazzi commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Fixes #39649

What does this PR do?

On Windows, Chromium/Electron fires compositionstart even for standard
English keyboard input, leaving composingRef.current = true when the
user presses Enter. The keydown handler checked composingRef.current
first and returned early, silently swallowing the Enter key.

Removing the composingRef check from the keydown guard fixes this —
event.nativeEvent.isComposing is sufficient and accurate across platforms.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

  • apps/desktop/src/app/chat/composer/index.tsx: removed composingRef.current
    from the IME guard in handleEditorKeyDown

How to Test

  1. Open Hermes Desktop on Windows
  2. Type any message in the composer
  3. Press Enter
  4. Message should send immediately without needing Shift+Enter first

Checklist

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits
  • My PR contains only changes related to this fix
  • I've tested on my platform: Windows 10

@alt-glitch alt-glitch added type/bug Something isn't working P3 Low — cosmetic, nice to have comp/tui Terminal UI (ui-tui/ + tui_gateway/) labels Jun 5, 2026
@alt-glitch alt-glitch added comp/desktop Electron desktop app (apps/desktop/*) platform/windows Native Windows-specific behavior or breakage and removed comp/tui Terminal UI (ui-tui/ + tui_gateway/) labels Jun 26, 2026
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for isolating the Windows Enter path. The current main handler still has the reported early return at apps/desktop/src/app/chat/composer/index.tsx:370, so this is a valid area to fix.

Problems

  • Removing the ref from only the keydown guard leaves the stale ref active elsewhere: handleEditorInput still drops input while it is true (apps/desktop/src/app/chat/composer/index.tsx:303-309), and the form handler still rejects Send-button submission (apps/desktop/src/app/chat/composer/index.tsx:827-834). The stale state should be repaired rather than only bypassed for Enter.
  • No test covers the reported false-composition sequence. Existing IME coverage ends composition normally (apps/desktop/src/app/chat/composer/ime-composition-dom-repro.test.tsx:61-83).

Suggested changes

  • Clear a stale composingRef when native isComposing is false before retaining the genuine-IME guard, and clear it on blur for the form-submit path.
  • Add the Windows-style DOM regression case and retain a genuine-IME Enter non-submit assertion.

Automated hermes-sweeper review.

@teknium1 teknium1 added sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 14, 2026
@iborazzi
iborazzi force-pushed the fix/session-search-v2 branch from 85053b4 to ffd0c03 Compare July 14, 2026 08:56
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/desktop Electron desktop app (apps/desktop/*) P3 Low — cosmetic, nice to have platform/windows Native Windows-specific behavior or breakage sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Desktop composer Enter key does not send message on Windows

3 participants