Firefox Japanese IME conversion candidate selection interferes with contenteditable selection
OS: macOS 12.0+ · Device: Desktop Any · Browser: Firefox 115.0+ · Keyboard: Japanese (IME)
Open case →Scenario
Firefox Japanese IME conversion candidate selection interferes with contenteditable selection
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-0223-japanese-ime-candidate-firefox | macOS 12.0+ | Desktop Any | Firefox 115.0+ | Japanese (IME) | draft |
Open a case to see the detailed description and its dedicated playground.
OS: macOS 12.0+ · Device: Desktop Any · Browser: Firefox 115.0+ · Keyboard: Japanese (IME)
Open case →Other scenarios that share similar tags or category.
Comprehensive system for managing IME (Input Method Editor) composition state across different browsers and IME implementations, including state tracking, event normalization, and cross-platform consistency.
On Firefox with Windows 10 and Korean IME, specific key combination during IME composition causes the editor to crash. The crash occurs when typing certain sequences with the Korean IME.
On macOS, using the accent menu (e.g., holding vowel key to select accented character, or using option+key combinations) does NOT consistently trigger standard IME composition events (`compositionstart`, `compositionupdate`, `compositionend`). This makes it difficult to distinguish accent menu input from IME input or regular 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.
Have questions, suggestions, or want to share your experience? Join the discussion below.