Scenario

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.

input
Scenario ID
scenario-chrome-caret-jumps-to-end-dom-manipulation

Details

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.

References

Scenario flow

Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.

React Flow mini map

Variants

Each row is a concrete case for this scenario, with a dedicated document and playground.

Case OS Device Browser Keyboard Status
ce-0317-chrome-caret-jumps-to-end-dom-manipulation Any Any Desktop or Laptop Any Chrome Latest 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: chrome, contenteditable

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: caret

Caret not visible in empty div on Firefox

Firefox may not show a caret in an empty block-level contenteditable container until the user types or a br placeholder exists—layout and min-height interact with focus rings.

1 case

Comments & Discussion

Have questions, suggestions, or want to share your experience? Join the discussion below.