ResizeObserver may cause layout shifts during contenteditable editing
OS: Windows 11 · Device: Desktop or Laptop Any · Browser: Chrome 120.0 · Keyboard: US
Open case →Scenario
ResizeObserver may cause layout shifts during contenteditable editing
When a ResizeObserver is attached to a contenteditable element, the observer may trigger during editing as content changes size. This can cause layout recalculations and visual jumps, especially when the contenteditable has dynamic height.
performance
Scenario ID
scenario-resize-observer-interference
Details
When a ResizeObserver is attached to a contenteditable element, the observer may trigger during editing as content changes size. This can cause layout recalculations and visual jumps, especially when the contenteditable has dynamic height.
References
- MDN: Resize Observer API - ResizeObserver documentation
- Medium: After MutationObserver, PerformanceObserver, IntersectionObserver - Observer timing
- BhojPress: Observer patterns in JavaScript - Performance optimization
- Stack Overflow: Dynamically height-adjusted textarea without reflows - Layout optimization
- W3C CSSWG Issue #9560: ResizeObserver loop limit - Loop limit issues
- Web.dev: Avoid large complex layouts - Layout thrashing
- CSS-Tricks: Content jumping avoid - Placeholder sizes
- Reddit: CSS layout quirks - Box model 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-0081-contenteditable-with-resize-observer | Windows 11 | 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: performance, chrome
Chrome spellcheck performance regression (v96 era)
A known Chromium regression around spellcheck and large contenteditable regions caused severe typing lag—documented for planning workarounds such as spellcheck=false or chunking.
1 case
Tags: performance, chrome
CSS filter may affect contenteditable performance
When a contenteditable element has CSS filters applied (blur, brightness, etc.), editing performance may be degraded. Typing may lag, and selection may be slow to update.
1 case
Tags: performance, chrome
CSS will-change may improve or degrade contenteditable performance
When a contenteditable element has CSS will-change property set, performance may be affected. In some cases, it may improve performance by hinting the browser about upcoming changes. In other cases, it may degrade performance by creating unnecessary layers.
1 case
Tags: layout, performance
Typing and layout performance in very large contenteditable documents
Huge DOM trees make each keystroke expensive: layout, style recalc, and spellcheck can block input—virtualization or chunking is often required.
1 case
Tags: performance, chrome
Virtual scrolling libraries interfere with contenteditable selection
When a contenteditable element is used with virtual scrolling libraries (e.g., for large documents), the virtual scrolling mechanism may interfere with text selection and caret positioning. The selection may be lost when elements are removed from the DOM during scrolling.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.