Chinese IME conversion delay and partial conversion in Safari
OS: macOS 14.0 · Device: Desktop or Laptop Any · Browser: Safari 17.0
Open case →Scenario
Japanese kanji conversion and Chinese character selection depend on the IME candidate window. Delays, wrong ordering, or Safari-specific lag can cause users to commit the wrong character or see candidates that do not match the underlying buffer—especially under load or in complex layouts.
Japanese kanji conversion and Chinese character selection depend on the IME candidate window. Delays, wrong ordering, or Safari-specific lag can cause users to commit the wrong character or see candidates that do not match the underlying buffer—especially under load or in complex layouts.
Conversion is not just a browser issue—IME software matters—but the host app (your editor) can worsen latency with synchronous layout, heavy input handlers, or forced layout reads.
Wrong characters committed; power users notice “sticky” conversion.
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0175-japanese-ime-kanji-conversion-chrome | Windows 11 | Desktop or Laptop Any | Chrome 120.0 | Japanese (IME) | draft |
| ce-0176-chinese-ime-conversion-delay-safari | macOS 14.0 | Desktop or Laptop Any | Safari 17.0 | Chinese (IME - Pinyin) | draft |
This matrix shows which browser and OS combinations have documented cases for this scenario. Click on a cell to view the specific case.
| Browser | Windows | macOS |
|---|---|---|
| Chrome | — | |
| Safari | — |
This scenario affects multiple languages. Cases are grouped by language/input method below.
OS: macOS 14.0 · Device: Desktop or Laptop Any · Browser: Safari 17.0
Open case →OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Chrome 120.0
Open case →Other scenarios that share similar tags or category.
Many IMEs let users pick candidates with number keys 1–9. In contenteditable, those keys may be consumed by the IME, intercepted by the page for shortcuts, or mis-handled by Safari—causing wrong selection or cancelled composition.
Moving focus away from the editor while composing text (Chinese, Japanese, Korean) can cancel composition, commit partial text, or leave the IME candidate window out of sync. Safari often shows distinct behavior for Japanese; Chrome behavior for Chinese/Korean is covered in related cases.
If the user switches focus to another field, button, or nested contenteditable while Korean (or other) IME composition is active, browsers differ on whether composition is committed, cancelled, or leaves orphan state. Chrome, Safari, and Firefox do not agree; mobile adds more variance.
User scrolling the page or scrollable editor while the IME candidate window is open may cancel composition or move the caret out of sync—reported on iOS Safari with Japanese IME and Android Chrome with Chinese IME when scroll containers move the editing context.
Tab moves focus by default. During IME composition, Tab may cancel composition, cycle candidates, or be captured by the editor for indentation—behavior differs for Chinese, Thai, and Safari vs Firefox.
Have questions, suggestions, or want to share your experience? Join the discussion below.