Bob Ippolito

Thank you for your contribution!

There are two selections: lexical's selection, and the DOM's selection. When you manipulate lexical's selection nothing happens to the DOM's selection until reconciliation (after the batch of update calls).

I think the `excludeFromCopy` approach discussed in #4273 would be easier to implement correctly and have fewer consequences for existing code (maybe using the `clone` destination? I don't see any...

I think there are three reasonable approaches: 1. Use `excludeFromCopy` with the existing `clone` destination. This will change semantics for nodes that implement this method without considering the destination. 2....

With a quick look at the monorepo code it seems that options 1 & 2 would probably break the current implementation of `OverflowNode`, since it unconditionally returns `true` from `excludeFromCopy`....

Closing this PR due to staleness! If there are new updates, please reopen the PR.

It doesn't really matter whether the NodeRegistration is created by the user (no static method requirement with that, but it is a separate identifier to export and use) or by...

I think changing this might cause some problems with things like dialogs and maybe the toolbar where the focus leaves the editor but is generally expected to be restored when...

Probably, although that's a pretty significant change and asking for different bugs ("updateEditor: selection has been lost…" in particular would be even easier to run into if selections were commonly...

This is basically a CSS issue, TabNode creates a span with only whitespace as content, and CSS won't do a strikethrough in that case since there isn't any "text".