Describe the bug
When a Heading node contains a LineBreakNode (inserted via Shift+Enter) and the user presses Enter to split the block, the heading type incorrectly transfers to the latter fragment. The original text loses its heading formatting and becomes a plain paragraph.
To Reproduce
- Create a Heading (e.g., select "Heading 1" from the Block Type dropdown)
- Type some text (e.g.,
first)
- Press Shift+Enter to insert a line break inside the heading
- Type more text (e.g.,
second)
- Press Enter to split into a new block
Expected behavior
# first ← heading type stays with the original text
second ← new paragraph
Actual behavior
first ← heading type is lost (downgraded to paragraph)
# second ← heading type incorrectly transferred here
Screenshots
Before Enter (Shift+Enter line break inside H1):
After Enter (heading transferred to wrong fragment):
Desktop
- OS: macOS
- Browser: Chrome
- MDXEditor version: 3.52.4
Additional context
We discovered this while building a form-integrated MDXEditor setup (MDXEditor + react-hook-form) where we needed to ensure the markdown round-trip (markdown → editor → markdown) produces consistent results.
Our use case involves saving editor content as markdown to a database and reloading it later. Since the markdown ↔ WYSIWYG round-trip is inherently lossy (CommonMark collapses multiple blank lines, etc.), we normalize content at save time using the same mdast-util-from-markdown / mdast-util-to-markdown pipeline that MDXEditor uses internally — to keep the saved value and editor display in sync.
While testing all block types (h1–h3, paragraph, blockquote, lists) for Enter vs Shift+Enter behavior to verify visual consistency between the editor and rendered output, we noticed this heading split issue. It breaks the assumption that block-level formatting stays with the original content when a block is split.
This also means that a heading containing a Shift+Enter, when saved and reloaded through the mdast round-trip, can produce a different structure than what the user originally authored — compounding the round-trip normalization problem.
Describe the bug
When a Heading node contains a LineBreakNode (inserted via Shift+Enter) and the user presses Enter to split the block, the heading type incorrectly transfers to the latter fragment. The original text loses its heading formatting and becomes a plain paragraph.
To Reproduce
first)second)Expected behavior
Actual behavior
Screenshots
Before Enter (Shift+Enter line break inside H1):
After Enter (heading transferred to wrong fragment):
Desktop
Additional context
We discovered this while building a form-integrated MDXEditor setup (MDXEditor + react-hook-form) where we needed to ensure the markdown round-trip (markdown → editor → markdown) produces consistent results.
Our use case involves saving editor content as markdown to a database and reloading it later. Since the markdown ↔ WYSIWYG round-trip is inherently lossy (CommonMark collapses multiple blank lines, etc.), we normalize content at save time using the same
mdast-util-from-markdown/mdast-util-to-markdownpipeline that MDXEditor uses internally — to keep the saved value and editor display in sync.While testing all block types (h1–h3, paragraph, blockquote, lists) for Enter vs Shift+Enter behavior to verify visual consistency between the editor and rendered output, we noticed this heading split issue. It breaks the assumption that block-level formatting stays with the original content when a block is split.
This also means that a heading containing a Shift+Enter, when saved and reloaded through the mdast round-trip, can produce a different structure than what the user originally authored — compounding the round-trip normalization problem.