Fix: IME input handling to prevent unintended message submission

[seijikohara]

Summary

This PR fixes a bug where pressing Enter to confirm IME (Input Method Editor) conversion unintentionally triggers message submission in chat interfaces.

Closes#19
Supersedes #278 (more comprehensive fix applied across all input components)

Problem

When users type with IME for East Asian languages, they press Enter to confirm character conversion (e.g., hiragana → kanji). The application incorrectly interpreted this Enter keypress as a submit action.

Root Cause

The justEndedRef flag reset logic was flawed:

// Before (incorrect)if(hasCompositionJustEndedRef.current&&keyCode!==229){hasCompositionJustEndedRef.current=false;}

Since Enter has keyCode === 13 (not 229), the condition keyCode !== 229 evaluated to true, resetting the flag before the Enter key check could use it.

Event Sequence Diagram

sequenceDiagram
participant User
participant IME
participant Browser
participant App
User->>IME: Type "nihon"
IME->>Browser: compositionstart
Browser->>App: Set isComposingRef = true
User->>IME: Press Enter (confirm)
IME->>Browser: compositionend
Browser->>App: Set isComposingRef = false
Browser->>App: Set justEndedRef = true
Browser->>App: keydown (Enter)
Note over App: Check justEndedRef → true
App->>App: Skip submission ✓
App->>App: Reset justEndedRef = false
User->>IME: Press Enter (submit)
Browser->>App: keydown (Enter)
Note over App: Check justEndedRef → false
App->>App: Submit message ✓

Loading

Solution

1. Fix Flag Reset Condition

Changed the reset condition to only reset on non-Enter keys:

// After (correct)if(justEndedRef.current&&e.key!=="Enter"){justEndedRef.current=false;}

2. Multi-Layered IME Detection

Implemented a detection strategy for cross-browser compatibility:

flowchart TD
A[keydown event] --> B{e.isComposing?}
B -->|true| Z[Skip: IME active]
B -->|false| C{native.isComposing?}
C -->|true| Z
C -->|false| D{isComposingRef?}
D -->|true| Z
D -->|false| E{keyCode === 229?}
E -->|true| Z
E -->|false| F{justEndedRef?}
F -->|true| Y[Skip: Just confirmed]
F -->|false| G[Process Enter]

Loading

Layer	Method	Purpose
Primary	isComposing property	Standard API (React/Native)
Secondary	Composition event tracking	Manual fallback
Tertiary	keyCode === 229	Safari/WKWebView edge cases

3. Shared Utilities (DRY/SSOT)

Created centralized utilities to eliminate code duplication:

src/
├── utils/
│ └── ime.ts # Single source of truth
└── hooks/
└── useIMESafeEnterSubmit.ts # Reusable hook

Comparison with #278

Aspect	#278	This PR
Components fixed	FloatingPromptInput only	All 5 input components
Flag reset bug fix	No	Yes (e.key !== "Enter")
Shared utilities	No	Yes (DRY/SSOT)
Custom hook	No	Yes (useIMESafeEnterSubmit)
onBlur cleanup	No	Yes

Changes

File	Change
src/utils/ime.ts	New: Shared IME detection utilities
src/hooks/useIMESafeEnterSubmit.ts	New: Custom hook for IME-safe Enter
src/components/FloatingPromptInput.tsx	Modified: Use shared utilities
src/components/ClaudeCodeSession.tsx	Modified: Use shared utilities
src/components/TimelineNavigator.tsx	Modified: Use shared utilities
src/components/WebviewPreview.tsx	Modified: Use shared utilities
src/components/AgentExecution.tsx	Modified: Use shared utilities

Supported Languages

This implementation is language-agnostic and supports any IME using composition events:

• Japanese (Hiragana/Katakana/Kanji)
• Chinese (Pinyin, Wubi, Zhuyin, Cangjie)
• Korean (Hangul)
• Vietnamese (Telex, VNI)
• Other composition-based input methods

Testing

• TypeScript type check (tsc --noEmit)
• Rust tests (9/9 passed)
• Manual testing with Japanese IME on macOS
• Verified: IME confirmation Enter does not submit
• Verified: Subsequent Enter correctly submits

References

• MDN: keydown event
• W3C UI Events Specification
• Handling IME Events in JavaScript