Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Pasting lists on lists results in potentially reordered content #4723

Closed
9larsons opened this issue Jun 29, 2023 · 5 comments
Closed

Bug: Pasting lists on lists results in potentially reordered content #4723

9larsons opened this issue Jun 29, 2023 · 5 comments
Labels
lists Relates to Lexical Lists

Comments

@9larsons
Copy link
Contributor

9larsons commented Jun 29, 2023

Lexical version: v0.11.1

Steps To Reproduce

  1. Create a list item with a child list item
  2. Paste text and list onto that content (see gif)

CleanShot 2023-06-29 at 12 19 27

The current behavior

See gif above. Pasted content can be re-ordered relative to what was in the document which is definitely unintentional (ie not all pasted content is inserted at the same spot).

The expected behavior

I'd expect content to be pasted and at least maintain the correct ordering. I feel like the indentation behavior is subjective. For example, Google Docs will paste lists relative to the current indendation/list depth, while Lexical appears to paste relative to parent nodes.

@9larsons
Copy link
Contributor Author

I believe the issue is definitely within this block. If I can find some time I'll do some more investigation.

@9larsons
Copy link
Contributor Author

This cannot be resolved while #5124 is out there, as the behavior that is intended to handle the node insertion is broken by the fact that an empty ElementNode is inserted prior to the content that was actually intended to be inserted (by way of copy actions in the editor).

You can test this by pasting from outside the editor, like a list from google docs, and it pastes in just fine (and as we'd expect it). The reason the re-order happens is because it ends up being treated as a whole new ListNode vs. a ListItemNode.

@9larsons
Copy link
Contributor Author

To be clear, this is the line where it fouls up. The firstAncestor ends up being a ListItemNode and not a TextNode if it's empty (and in this case we're always adding an empty line).

Because of this, it ends up getting appended to the end instead of inserted as one would expect.

@ivailop7
Copy link
Collaborator

@9larsons are you open to fixing this upstream?

@9larsons
Copy link
Contributor Author

This seems resolved when testing again in v0.13.1 - seems likely it was handled with the changes to insertNodes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lists Relates to Lexical Lists
Projects
None yet
Development

No branches or pull requests

3 participants