Composition events not triggered in iOS Safari with Korean keyboard
OS: iOS Any · Device: Mobile Any · Browser: Safari Latest · Keyboard: Korean
Open case →Scenario
On some iOS Safari versions and keyboards, compositionstart or compositionupdate may not fire reliably for certain languages, while input events still fire—editors that only reconcile on composition boundaries can desync.
On some iOS Safari versions and keyboards, compositionstart or compositionupdate may not fire reliably for certain languages, while input events still fire—editors that only reconcile on composition boundaries can desync.
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-0550-ime-composition-events-missing-ios | iOS Any | Mobile Any | Safari Latest | Korean | draft |
Open a case to see the detailed description and its dedicated playground.
OS: iOS Any · Device: Mobile Any · Browser: Safari Latest · Keyboard: Korean
Open case →Other scenarios that share similar tags or category.
Some browsers and keyboards emit duplicate composition-related input or beforeinput events—especially iOS Safari dictation paths and certain Android keyboards—so naive handlers that insert text on every input may double characters or corrupt state.
On iOS, when using voice dictation to input text into contenteditable elements, the system may fire duplicate beforeinput and input events after the initial dictation completes. The text is split into words and events are re-fired, causing synchronization issues. Composition events do not fire during dictation, making it difficult to distinguish dictation from keyboard input.
During IME composition or in certain browser/IME combinations, the beforeinput event may have a different inputType than the corresponding input event. For example, beforeinput may fire with insertCompositionText while input fires with deleteContentBackward. This mismatch can cause handlers to misinterpret the actual DOM change and requires storing beforeinput's targetRanges for use in input event handling.
The selection (window.getSelection()) in beforeinput events can differ from the selection in corresponding input events. This mismatch can occur during IME composition, text prediction, or when typing adjacent to formatted elements like links. The selection in beforeinput may include adjacent formatted text, while input selection reflects the final cursor position.
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.
Have questions, suggestions, or want to share your experience? Join the discussion below.