beforeinput event not cancelable during IME composition
OS: Windows Any · Device: Desktop or Laptop Any · Browser: Chrome Latest · Keyboard: Korean
Open case →Scenario
Some beforeinput events during IME composition cannot be canceled per spec or implementation—calling preventDefault may throw or be ignored, so editors cannot always block native insertion.
Some beforeinput events during IME composition cannot be canceled per spec or implementation—calling preventDefault may throw or be ignored, so editors cannot always block native insertion.
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-0305-beforeinput-not-cancelable-ime | Windows Any | Desktop or Laptop Any | Chrome Latest | Korean | draft |
Open a case to see the detailed description and its dedicated playground.
OS: Windows Any · Device: Desktop or Laptop Any · Browser: Chrome Latest · Keyboard: Korean
Open case →Other scenarios that share similar tags or category.
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.
The getTargetRanges() method in beforeinput events may return an empty array or undefined in various scenarios, including text prediction, certain IME compositions, or specific browser/device combinations. When getTargetRanges() is unavailable, developers must rely on window.getSelection() as a fallback, but this may be less accurate.
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.
In Safari desktop, when preventDefault() is called on keydown or beforeinput events for insertParagraph (Enter key), the IME composition state becomes corrupted. Subsequent text input fails to trigger proper input events, causing characters to not be inserted or composition to malfunction.
Have questions, suggestions, or want to share your experience? Join the discussion below.