Cursor disappears when clicking on contenteditable with non-editable children in Firefox
OS: Any Any · Device: Desktop or Laptop Any · Browser: Firefox Latest · Keyboard: US
Open case →Scenario
Cursor disappears near contenteditable=false boundaries in Firefox
Firefox may hide or misplace the caret when moving across contenteditable=true/false boundaries—widgets and embeds inside editors are affected.
input
Scenario ID
scenario-firefox-contenteditable-false-cursor-disappears
Details
Firefox may hide or misplace the caret when moving across contenteditable=true/false boundaries—widgets and embeds inside editors are affected.
Related Cases
References
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-0309-firefox-contenteditable-false-cursor-disappears | Any Any | Desktop or Laptop Any | Firefox 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: contenteditable, caret
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: firefox, 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: firefox, 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
Tags: firefox, 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
Tags: firefox
Drag-and-drop duplicates elements in Firefox
Dragging selected content inside a contenteditable region on Firefox can duplicate nodes or leave ghost fragments—different from Chrome's behavior.
1 case
Comments & Discussion
Have questions, suggestions, or want to share your experience? Join the discussion below.