Slate: Backwards selection anchored at the end of an inline block has unexpected behavior

[JonathanWbn]

Do you want to request a _feature_ or report a _bug_?

Bug

What's the current behavior?

Selecting text when starting at the end of the line and that end being a link the selecting doesn't work.

Slate: 0.57.1
Browser: Chrome
OS: Mac

[kilrain]

I dug into this bug over the weekend a bit. The issue seems to have to do with the zeroWidthString node inserted after an inline. Native DOM selection has a tendency to put the offset AFTER the zero width character (offset: 1) while Slate prefers to consider this state as offset: 0.

On the initial mousedown, the native selectionchange event sets the cursor to offset of 1... immediately, Slate resets the offset to 0. After beginning to drag, native selection reverts to an anchor offset of 1 and Slate processes the update but, again, considers it as an offset of 0. This doesn't trigger a re-render (since Slate already thinks the selection anchor is offset 0), thus the useLayoutEffect does not get a chance to sync the DOM.

When Slate goes to re-render (as a result of the selection focus update) a native selectionchange event fires with the collapsed selection state we see in this bug. I could not successfully figure out where the collapsing selectionchange event is coming from. If I dragged the mouse very slowly over a void inline node, I could get into a valid state where the void node was selected... but if I continue dragging another pixel, the selection would collapse on the other side of the void node (as we see in the original bug report).

EDIT: by the way, I was working from commit 22d9095c (0.57.1 release)

[JonathanWbn]

Thank you, @kilrain, this was helpful. I found a solution and opened this PR: #3574.