contenteditable="false" on child elements is not respected consistently
OS: Any Ubuntu 22.04 · Device: Desktop or Laptop Any · Browser: Chrome 120.0 · Keyboard: US
Open case →Scenario
contenteditable="false" on child elements is not respected consistently
When a contenteditable region contains child elements with contenteditable="false", the behavior is inconsistent. Some browsers allow editing within these elements, while others correctly prevent it.
other
Scenario ID
scenario-contenteditable-readonly
Details
When a contenteditable region contains child elements with contenteditable="false", the behavior is inconsistent. Some browsers allow editing within these elements, while others correctly prevent it.
References
- MDN: contenteditable global attribute - contenteditable documentation
- Stack Overflow: contenteditable false inside contenteditable true IE8 - IE8 issues
- Microsoft Learn: UWP WebView contenteditable false - WebView issues
Scenario flow
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Variants
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0040-contenteditable-readonly | Any Ubuntu 22.04 | Desktop or Laptop Any | Chrome 120.0 | US | draft |
Cases
Open a case to see the detailed description and its dedicated playground.
Related Scenarios
Other scenarios that share similar tags or category.
Tags: contenteditable, chrome
contenteditable=false dismisses selection on Android Chrome
Tapping or moving across contenteditable=false regions on Android can collapse selection or clear the caret in ways that differ from desktop Chrome.
1 case
Tags: contenteditable, chrome
Auto-scroll while typing in contenteditable
Browsers try to keep the caret visible by scrolling the editable container or the page. During rapid typing—especially near the bottom or right edge—scroll updates can lag, batch, or feel jarring, so the caret temporarily leaves the viewport or the view jumps unexpectedly.
3 cases
Tags: contenteditable, chrome
Caret jumps to end after DOM manipulation in Chrome
In Chromium, programmatic DOM updates (normalization, wrapping, React reconciliation) while the user is typing can move the caret to the end of the contenteditable or to an unexpected boundary—especially when the mutation happens between keystrokes.
1 case
Tags: contenteditable, chrome
HTML Drag and Drop API with contenteditable
Using the HTML drag-and-drop API inside or alongside contenteditable regions often diverges from behavior on plain elements: default actions, `contenteditable` hit-testing, and `beforeinput`/`drop` ordering differ by browser. Custom editors must reconcile native DnD with their own selection model.
1 case
Tags: nested, contenteditable
getTargetRanges() can reference the wrong contenteditable when editors are nested
On some engines (notably Firefox for Android / Fenix), beforeinput getTargetRanges() may describe the outer contenteditable host instead of the inner focused editor. Custom handlers that trust targetRanges alone may delete or insert in the parent surface while the user believes they are typing in a nested field.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.