contenteditable behavior differs when inside an iframe
OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Edge 120.0 · Keyboard: US
Open case →Scenario
contenteditable behavior differs when inside an iframe
When a contenteditable region is inside an iframe, its behavior may differ from when it's in the main document. Selection, focus, and event handling may be inconsistent.
other
Scenario ID
scenario-contenteditable-iframe
Details
When a contenteditable region is inside an iframe, its behavior may differ from when it’s in the main document. Selection, focus, and event handling may be inconsistent.
References
- AllowFullscreen: Cross-origin restrictions in iframes - Same-origin policy
- Stack Overflow: Tracking focus on cross-origin iframe - Focus detection
- XJavaScript: Blocked autofocusing in cross-origin subframe - postMessage communication
- Stack Overflow: How to detect a click inside of an iframe cross-domain - Click detection
- Stack Overflow: Detecting when an iframe gets or loses focus - Focus polling
- Stack Overflow: Selection change event in contenteditable - selectionchange event
- GitHub Gist: iOS Safari iframe focus issues - iOS-specific workarounds
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-0048-contenteditable-in-iframe | Windows 11 | Desktop or Laptop Any | Edge 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
role="textbox" and screen reader behavior with contenteditable
Assistive technologies map contenteditable to textbox-like semantics when authors use role=textbox or aria-multiline—conflicts with actual HTML semantics and browser AX trees can confuse announcements.
1 case
Tags: contenteditable
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
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
Browser extensions interfering with contenteditable (Grammarly and others)
Extensions inject overlays, mutate DOM, or listen to input for grammar and translation—breaking framework-controlled editors, selection restoration, and IME composition boundaries.
1 case
Tags: contenteditable
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
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.