ProseMirror: splitBlock crashes on specific node nesting
OS: Windows 11 · Device: Desktop Any · Browser: All Browsers n/a · Keyboard: US QWERTY
Open case →Scenario
Paragraph splitting and block behavior in editors
Enter key handling, splitBlock commands, and browser-default paragraph creation differ—ProseMirror and native contenteditable can disagree, causing crashes or empty blocks at boundaries.
input
Scenario ID
scenario-paragraph-behavior
Details
Enter key handling, splitBlock commands, and browser-default paragraph creation differ—ProseMirror and native contenteditable can disagree, causing crashes or empty blocks at boundaries.
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-0576-prosemirror-splitblock-crash | Windows 11 | Desktop Any | All Browsers n/a | US QWERTY | confirmed |
Cases
Open a case to see the detailed description and its dedicated playground.
Related Scenarios
Other scenarios that share similar tags or category.
Tags: paragraph
Empty paragraphs and br handling in contenteditable
Browsers disagree on how empty blocks are represented (<p><br></p>, <p></p>, <div><br></div>) and how Backspace merges them. Editors that normalize on every keystroke can fight the user or create nested spans.
1 case
Category: input
innerHTML and serialization differ across browsers
The same DOM edited in contenteditable may serialize to different markup strings in Safari vs Chrome—attribute order, implied tags, and span wrappers for styles.
1 case
Category: input
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
Category: input
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
Category: input
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.