Do NOT use exact match when updating dom selection

[davidruisinger]

Description
When there is NO text, yet within a nested, editable void Slate Editor (see editable voids example, starting to type some text leads to backwards typing.

Issue
Fixes: #4293

Example
Before:

After:

Context
The bug seems to have been introduced with #4157 so it would be great if @githoniel could have another look at this

Checks

• The new code matches the existing patterns and styles.
• The tests pass with yarn test.
• The linter passes with yarn lint. (Fix errors with yarn fix.)
• The relevant examples still work. (Run examples with yarn start.)
• You've added a changeset if changing functionality. (Add one with yarn changeset add.)

[changeset-bot]

🦋 Changeset detected

Latest commit: 528d3c0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
slate-react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[githoniel]

thanks for metion

I think this is ReactEditor.toSlateRange problem.

after typing when text in empty, DOM Selection is

ReactEditor.toSlateRange convert it to offset: 1 while it should be offset: 0, so Slate point to start after selection sync. I think We should fix it.

[davidruisinger]

thanks for metion

I think this is ReactEditor.toSlateRange problem.

after typing when text in empty, DOM Selection is

ReactEditor.toSlateRange convert it to offset: 1 while it should be offset: 0, so Slate point to start after selection sync. I think We should fix it.

I tried to debug the toSlateRange method and I the problem seems to be within toSlatePoint. There is a difference between "normal" nodes and void nodes when setting the offset.
In "normal" nodes, the offset is calculated by the length of the text of a DocumentFragment that is received through a created range (see here).
In void nodes, the length is also taken from a text length, but this time the domNode itself is used (see here).

Unfortunately I wasn't able to find a fix, yet. I'd really appreciate if someone else could have a look at this as well.

[hueyhe]

I also ran into this issue. After debugging the toSlatePoint, I think the problem is caused by the unexpected element type of the anchor/focus node of the DOM selection.

Here in toSlatePoint, the nearestNode, which refers to the domPoint if exact match is used, is expected to be an html text node. However, the anchor/focus node of the DOM selection we got from here isn't always a text node.

In the case below, the anchor node of the DOM selection is the editable DOM element rather than the html text node. So toSlatePoint can't find the corresponding slate point of the anchor node.

Screen.Recording.2021-06-26.at.2.47.43.PM.mov

The DOM selection after deletion:

Things work fine outside the editable void because the leaf node will always be undefined and won't be corrected by the void node. So the DOM selection is always updated by the slate selection since it's out of sync.

[githoniel]

I will look this later. I think we should fix toSlateRange instead

[zbeyens]

This cursor bug makes the nested editors unusable in production, I would be in favor to merge this until we find a fix inside toSlateRange.

[dylans]

Accepting and landing this for now, until we can come up with something better.