run-llama/chat-ui
1
0
Fork 0
mirror of https://github.com/run-llama/chat-ui.git synced 2026-07-24 15:45:22 -04:00
Code Issues 13 Packages Projects Releases 10 Wiki Activity

[PR #142] [CLOSED] Fix: Prevents incorrect input commitment when selecting IME candidates #156

New Issue
Closed
opened 2026-02-16 03:15:24 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 03:15:24 -05:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/run-llama/chat-ui/pull/142
Author: @BaiRuic
Created: 6/20/2025
Status: ❌ Closed

Base: main ← Head: fix/ime-composition-race-condition

📝 Commits (2)

  • cc8b061 fix: resolve race condition during IME composition
  • 943fe14 Create tricky-ravens-cheer.md

📊 Changes

2 files changed (+8 additions, -1 deletions)

View changed files

➕ .changeset/tricky-ravens-cheer.md (+5 -0)
📝 packages/chat-ui/src/chat/chat-input.tsx (+3 -1)

📄 Description

This pull request addresses an issue where the Pinyin string is prematurely committed when a user selects a Chinese character candidate using a number key. (This PR is aimed to fix #135 )

The Problem

When using an IME (e.g., Chinese Pinyin) in the ChatInputField component, the following incorrect behavior occurs:

  1. A user types a Pinyin string (e.g., "nihao"), and the IME displays a candidate list.
  2. The user presses a number key (e.g., '1') to select the corresponding word ("你好").
  3. Expected behavior: The input field should be updated with the selected Chinese characters ("你好").
  4. Actual behavior: The underlying Pinyin string ("nihao") is committed to the input field, instead of being replaced by the selected candidate.

The Root Cause

This issue stems from a subtle event ordering problem on certain platforms. When the number key is pressed to select a candidate, the compositionend event can fire before the keydown event.
This causes our isComposing state to be set to false prematurely. Immediately after, when the handleKeyDown function processes the number key's keydown event, it sees isComposing as false and may incorrectly handle the key press, causing the then-current value (the Pinyin) to be treated as final. The IME's replacement of Pinyin with the actual characters happens after this, but by then it's too late.

The Solution

To resolve this, this PR introduces a setTimeout to the onCompositionEnd event handler.

// Before
onCompositionEnd={() => setIsComposing(false)}

// After
onCompositionEnd={() => {
  setTimeout(() => setIsComposing(false), 100)
}}

By delaying the execution of setIsComposing(false), we ensure that the isComposing flag remains true until after the keydown event has been fully processed. This allows handleKeyDown to correctly ignore the key event, giving the IME the necessary time to complete its composition and correctly update the input field with the selected characters.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/run-llama/chat-ui/pull/142 **Author:** [@BaiRuic](https://github.com/BaiRuic) **Created:** 6/20/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/ime-composition-race-condition` --- ### 📝 Commits (2) - [`cc8b061`](https://github.com/run-llama/chat-ui/commit/cc8b06106bc4207a401dd276f16dc03868e9c100) fix: resolve race condition during IME composition - [`943fe14`](https://github.com/run-llama/chat-ui/commit/943fe14a4189800384606bd8c0d867a398004ba9) Create tricky-ravens-cheer.md ### 📊 Changes **2 files changed** (+8 additions, -1 deletions) <details> <summary>View changed files</summary> ➕ `.changeset/tricky-ravens-cheer.md` (+5 -0) 📝 `packages/chat-ui/src/chat/chat-input.tsx` (+3 -1) </details> ### 📄 Description This pull request addresses an issue where the Pinyin string is prematurely committed when a user selects a Chinese character candidate using a number key. (This PR is aimed to fix #135 ) ## The Problem When using an IME (e.g., Chinese Pinyin) in the `ChatInputField` component, the following incorrect behavior occurs: 1. A user types a Pinyin string (e.g., "nihao"), and the IME displays a candidate list. 2. The user presses a number key (e.g., '1') to select the corresponding word ("你好"). 3. **Expected behavior**: The input field should be updated with the selected Chinese characters ("你好"). 4. **Actual behavior**: The underlying Pinyin string ("nihao") is committed to the input field, instead of being replaced by the selected candidate. ## The Root Cause This issue stems from a subtle event ordering problem on certain platforms. When the number key is pressed to select a candidate, the `compositionend` event can fire before the `keydown` event. This causes our `isComposing `state to be set to `false` prematurely. Immediately after, when the `handleKeyDown` function processes the number key's `keydown` event, it sees `isComposing` as `false` and may incorrectly handle the key press, causing the then-current value (the Pinyin) to be treated as final. The IME's replacement of Pinyin with the actual characters happens after this, but by then it's too late. ## The Solution To resolve this, this PR introduces a `setTimeout` to the `onCompositionEnd` event handler. ```javascript // Before onCompositionEnd={() => setIsComposing(false)} // After onCompositionEnd={() => { setTimeout(() => setIsComposing(false), 100) }} ``` By delaying the execution of `setIsComposing(false)`, we ensure that the `isComposing` flag remains `true` until after the `keydown` event has been fully processed. This allows `handleKeyDown` to correctly ignore the key event, giving the IME the necessary time to complete its composition and correctly update the input field with the selected characters. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-02-16 03:15:24 -05:00
yindo closed this issue 2026-02-16 03:15:24 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
pull-request
Mirrored from GitHub Pull Request
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: run-llama/chat-ui#156
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?