Bug: Pasting in block results in pasting the content twice in Firefox

[GermanJablo]

Originally reported here: payloadcms/payload#10634

Lexical version: 0.23.1

Steps To Reproduce

1. open https://playground.lexical.dev/ in Firefox
2. Insert a poll component
3. When the selection is outside the poll, click on one of the inputs and paste something
4. The content will be pasted in duplicate inside and outside the poll

decoratorselection.mov

Apparently it's a selection issue. There is no generic logic that selects any decoratorNode when clicked, but this is done only on some specific decoratorNodes.

The current behavior

The content will be pasted in duplicate inside and outside the poll

The expected behavior

The content should be pasted only inside the poll

I have a fix on the way.

[etrepum]

I think the best solution to this is probably something else. If it was merely a decorator node selection issue then the issue wouldn't be platform specific. It seems more like there's something wrong with the logic that determines whether to handle an event in a contentEditable=false or not, because also in chrome cmd-A is being captured while that input is focused but that probably shouldn't be the case. Firefox doesn't prevent cmd-A from going to the poll input. The review app in #7072 doesn't fix any of that.

[GermanJablo]

I would describe it as a selection problem + something else (which makes it platform specific).

The Lexical selection still being outside the decorator when the cursor is inside is a bug regardless of whether there is something wrong with the events on contentEditable.

This is just one of the possible side effects that can occur. The one described at the end of #6632 is another. Who knows how many more there may be.

[etrepum]

There multiple scenarios where the lexical selection doesn't match the browser's selection by design, otherwise the SelectionAlwaysOnDisplay plug-in would have no purpose. I'm sure that some coherent solution exists but we should come up with something that solves all of the known quirks especially if we need to break compatibility to fix it.

Not having done much investigation here but knowing the internals a bit perhaps a closer solution would be to by default ignore all events with targets that are inside decorators (some of this already happens, e.g. $isSelectionCapturedInDecorator and isSelectionCapturedInDecoratorInput - these are not really relevant to the lexical selection per se as the inputs are DOM nodes) and have a way for them to explicitly forward them up to the parent editor. Maybe this could be done with a a command, possibly combined with a method on the decorator that toggles whether this happens by default or not. Selection might also have similar treatment particularly around keyboard navigation - not all decorator nodes have a sensible "single node selection", e.g. there's no reason why you would want a NodeSelection to happen for a HorizontalRuleNode since there is no internal content or editable state, a RangeSelection with element coordinates is fine and you would really want it to always be collapsed unless you're explicitly trying to select the node by holding the shift key or dragging.