Summary
On macOS, pressing Enter to confirm a Chinese IME candidate while editing an earlier user message submits the inline edit and opens the destructive edit-and-rerun confirmation dialog. The user cannot finish entering the Chinese text normally.
The bottom conversation composer does not reproduce the problem.
Area
Web UI / Desktop app
Reproduction or evidence
- Open a local conversation with at least one completed Turn whose user message contains ordinary text and no persisted reference capsules.
- Start editing that earlier user message.
- Switch to a Chinese IME and type pinyin until the candidate window is open.
- Press Enter to confirm the candidate.
- Observe that BitFun opens the edit-and-rerun confirmation dialog instead of leaving the editor open with the confirmed Chinese text.
Expected behavior
Enter events used to confirm an active IME candidate stay with the input method. The inline editor submits only on a real Enter action after composition has finished.
Actual behavior
The IME confirmation Enter invokes inline edit submission and opens the rerun confirmation dialog.
Environment
- BitFun commit: 6fed381
- OS: macOS
- Input: Chinese IME
- Surface: plain inline edit-and-rerun textarea in a completed conversation
Investigation
Ordinary text-only messages use the plain textarea path in UserMessageEditComposer. Its Enter-to-submit handler does not check native isComposing, tracked composition state, or keyCode 229, and the textarea does not wire composition start/end callbacks.
Reference-bearing messages use RichTextInput instead. That component already tracks composition and suppresses IME-owned Enter and Escape before invoking the outer edit-composer key handler, so the missing guard is scoped to the plain textarea path.
The bottom ChatInput already has equivalent protection from the earlier fix for #70. Inline editing was introduced after that fix and the plain path did not inherit the same IME guard. The existing UserMessageEditComposer component test has no IME or keyboard-submission coverage.
No matching open issue was found in searches for IME, input method, composition, Enter, and edit-and-rerun.
Related
Regression class related to #70, but on the later plain inline message-editing input path.
Summary
On macOS, pressing Enter to confirm a Chinese IME candidate while editing an earlier user message submits the inline edit and opens the destructive edit-and-rerun confirmation dialog. The user cannot finish entering the Chinese text normally.
The bottom conversation composer does not reproduce the problem.
Area
Web UI / Desktop app
Reproduction or evidence
Expected behavior
Enter events used to confirm an active IME candidate stay with the input method. The inline editor submits only on a real Enter action after composition has finished.
Actual behavior
The IME confirmation Enter invokes inline edit submission and opens the rerun confirmation dialog.
Environment
Investigation
Ordinary text-only messages use the plain textarea path in UserMessageEditComposer. Its Enter-to-submit handler does not check native isComposing, tracked composition state, or keyCode 229, and the textarea does not wire composition start/end callbacks.
Reference-bearing messages use RichTextInput instead. That component already tracks composition and suppresses IME-owned Enter and Escape before invoking the outer edit-composer key handler, so the missing guard is scoped to the plain textarea path.
The bottom ChatInput already has equivalent protection from the earlier fix for #70. Inline editing was introduced after that fix and the plain path did not inherit the same IME guard. The existing UserMessageEditComposer component test has no IME or keyboard-submission coverage.
No matching open issue was found in searches for IME, input method, composition, Enter, and edit-and-rerun.
Related
Regression class related to #70, but on the later plain inline message-editing input path.