Browser translation breaks contenteditable editing
OS: Any Any · Device: Desktop or Laptop Any · Browser: Chrome Latest · Keyboard: US
Open case →Scenario
When browser translation features (like Google Translate) are activated, they manipulate the DOM by replacing text content and injecting elements. This can break contenteditable functionality, causing cursor positioning issues, event handling problems, and IME composition failures.
When browser translation features (like Google Translate) are activated, they manipulate the DOM by replacing text content and injecting elements. This can break contenteditable functionality, causing cursor positioning issues, event handling problems, and IME composition failures.
<span> or <div> elementsUse translate="no" attribute:
<div contenteditable="true" translate="no">
Editable content that should not be translated
</div>
Google Translate respects this class:
<div contenteditable="true" class="notranslate">
Editable content
</div>
Use MutationObserver to restore attributes:
const observer = new MutationObserver((mutations) => {
for (const mutation of mutations) {
if (mutation.type === 'attributes' &&
mutation.attributeName === 'contenteditable') {
// Reapply contenteditable if removed
if (!mutation.target.hasAttribute('contenteditable')) {
mutation.target.setAttribute('contenteditable', 'true');
}
}
}
});
observer.observe(editableElement, {
attributes: true,
attributeFilter: ['contenteditable']
});
Detect editing mode and disable translation:
let isEditing = false;
editableElement.addEventListener('focus', () => {
isEditing = true;
document.documentElement.setAttribute('translate', 'no');
});
editableElement.addEventListener('blur', () => {
isEditing = false;
document.documentElement.removeAttribute('translate');
});
Use robust editor libraries that handle DOM mutations better:
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-0562-browser-translation-breaks-editing | Any Any | Desktop or Laptop Any | Chrome Latest | US | draft |
Open a case to see the detailed description and its dedicated playground.
OS: Any Any · Device: Desktop or Laptop Any · Browser: Chrome Latest · Keyboard: US
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.
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.
Have questions, suggestions, or want to share your experience? Join the discussion below.