Bug: Selection cursor grabs empty adjacent parent nodes

[9larsons]

When using Shift+Up or selecting with the mouse drag, the selection cursor tends to grab adjacent parent nodes (and none of their content). The end result of this is that any cut/copy/paste actions insert an empty parent node.

Example using paragraphs with Shift+Up, although the same applies to using the mouse:
https://github.com/facebook/lexical/assets/21961100/b2b1b30d-680e-4a10-b9df-e93aa1421248

Lexical version: v0.12.2

Steps To Reproduce

1. Type a word
2. Hit enter
3. Type another word
4. Use Shift+Up to select the whole second paragraph
5. Copy+paste

You will see an empty paragraph node inserted. This is because the selection contains the first ParagraphNode but none of the child nodes within it.

The current behavior

Extra empty nodes are being inserted.

The expected behavior

Only nodes containing content should be inserted.

[9larsons]

This is obviously a question of very core behavior. The problem is that we're creating unnecessary empty nodes when pasting content because of the current selection behavior. While not a problem for inline content, it does become a problem when writing something with multiple children of the root node.

This has downstream effects like #4723 because the existing handling doesn't account for empty nodes (as people generally can't copy and paste empty nodes).

It feels like it may be more appropriate for the Point to use an element type rather than a text type when there's no text selected. I don't know that this is entirely correct, but it would provide us some way to know that we're 'inbetween' nodes in the Lexical structure.

[9larsons]

CleanShot.2023-10-16.at.20.08.49.mp4

This is a very simple example of the behavior that clearly feels incorrect. I wouldn't expect the first ParagraphNode and child TextNode to return isSelected = true when all I'm trying to do is select the whole (second) ParagraphNode with Shift+Up.

If you're copying and pasting content over itself, there should obviously be no change.

[funbinhe1996]

Hi @9larsons thanks for your feedback, yes I can reproduce it.

[zurfyx]

Thanks for details, I think adjusting the selection is reasonable, it resembles the triple-click use case @fantactuka fixed some months ago #4512

Actually, other editors and even the native contenteditable don't do that so I would dare to say that the behavior is intended.