Selection range is incorrect when selecting across multiple elements
OS: Windows 11 · Device: Desktop Any · Browser: Edge 120.0 · Keyboard: US
Open case →Scenario
When selecting text that spans across multiple HTML elements (e.g., p, div, span) in a contenteditable region, the selection range may not accurately reflect the visual selection. The Selection and Range APIs may return incorrect boundaries.
When selecting text that spans across multiple HTML elements (e.g., <p>, <div>, <span>) in a contenteditable region, the selection range may not accurately reflect the visual selection. The Selection and Range APIs may return incorrect boundaries.
Range.startOffset and Range.endOffset may be incorrect when spanning element boundaries.<p>First</p><p>Second</p>.Selection object.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-0033-selection-range-incorrect | Windows 11 | Desktop Any | Edge 120.0 | US | confirmed |
Open a case to see the detailed description and its dedicated playground.
OS: Windows 11 · Device: Desktop Any · Browser: Edge 120.0 · Keyboard: US
Open case →Other scenarios that share similar tags or category.
When a contenteditable element has CSS transforms applied (translate, scale, rotate), the selection handles and caret may appear in incorrect positions. The visual position may not match the actual selection position.
After programmatically manipulating the DOM in a contenteditable element, restoring the text selection (cursor position) is unreliable across browsers. The selection may be lost, moved to an incorrect position, or become invalid.
When the browser is zoomed (or content is scaled via CSS transforms), caret position and text selection in contenteditable elements can become inaccurate. Clicking at a certain position places the caret elsewhere, and selection highlights may not match the visual selection.
When contenteditable='false' elements are placed inside a contenteditable container, the cursor may disappear or become invisible in certain browsers, making it difficult for users to determine the text insertion point.
After copying selected text in a contenteditable region using Cmd+C, the selection is lost in Safari. The user must re-select the text to perform additional operations.
Have questions, suggestions, or want to share your experience? Join the discussion below.