Korean IME composition causes Firefox editor crash
OS: Windows 10 · Device: Desktop Any · Browser: Firefox 120+ · Keyboard: Korean (IME) - Microsoft IME
Open case →Scenario
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 Firefox with Windows 10 and Korean IME, specific key combination sequences during IME composition can cause the contenteditable editor to crash unexpectedly.
This issue occurs specifically when:
Based on the GitHub issue, the crash sequence is:
Firefox’s IME handling appears to have a race condition or memory corruption when:
Prevent Ctrl+Shift+Home during composition:
let isComposing = false;
editor.addEventListener('compositionstart', () => {
isComposing = true;
});
editor.addEventListener('keydown', (e) => {
if (isComposing && e.ctrlKey && e.shiftKey && e.key === 'Home') {
e.preventDefault();
// Prevent problematic key combination during IME
}
});
editor.addEventListener('compositionend', () => {
isComposing = false;
});
Try-catch around critical operations:
editor.addEventListener('input', (e) => {
try {
// Handle input event
} catch (error) {
console.error('Input error:', error);
// Recover gracefully
}
});
Use try-finally for cleanup:
try {
// IME operations
} finally {
// Always cleanup state
}
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-0261-korean-ime-crash-firefox-en | Windows 10 | Desktop Any | Firefox 120+ | Korean (IME) - Microsoft IME | draft |
Open a case to see the detailed description and its dedicated playground.
OS: Windows 10 · Device: Desktop Any · Browser: Firefox 120+ · Keyboard: Korean (IME) - Microsoft IME
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.
Analysis of how out-of-order or missing composition events disrupt editor state synchronization.
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.
When using IME to input CJK text in heading elements (H1, H2, etc.) in WebKit browsers, pressing Space to confirm composition causes both the raw Pinyin buffer AND the confirmed characters to appear together.
Have questions, suggestions, or want to share your experience? Join the discussion below.