[lexical-overflow] Make OverflowNode a proper inline element (revisit #6027 / #6535) #9454

Summary

OverflowNode (@lexical/overflow, used by the character limit plugin) wraps the overflowing part of a paragraph's text, but its isInline() returns false. It behaves like an inline element while reporting itself as a block, so code that reasons about inline vs block content has to special-case it.

History

• Fix OverflowNode configuration #6027 (May 2024) made it a proper inline element: isInline(): true and canBeEmpty(): false.
• Revert "Fix OverflowNode configuration" #6535 (Aug 2024) reverted that, because the caret landed in the wrong place around a LineBreakNode:
  • in plain text mode, the insertion point always ended up before the trailing LineBreakNode;
  • in rich text mode, the same happened after Shift+Return inserted a LineBreakNode into a paragraph.
• Bug: Regression in test suite after merging #6027 (Fix OverflowNode configuration) #6534 tracked the regression. The revert said the change should be revisited with more tests.

Why it matters now

Code that relies on a node's inline/block nature has to treat OverflowNode as an exception, for example a content-model normalization that lifts block elements out of paragraphs. With isInline() true, it would be an ordinary inline element and need no exemption.

Proposal

1. Add e2e and unit tests for caret placement around LineBreakNode with the character limit active, in plain text and in rich text (Shift+Return, typing at the end, backspace across the boundary).
2. Re-apply the Fix OverflowNode configuration #6027 change.
3. Fix the selection or caret logic that misplaces the insertion point next to a trailing LineBreakNode inside an inline element.