If insertText does nothing, text is inserted into the DOM anyway, causing DOM/Slate desync (bug introduced in slate-react 0.66.0)

[jameshfisher]

Description
It is valid for insertText to return without doing anything. The expected behavior is that the document is left unchanged. For example, you might want to disallow typing uppercase characters -- you can do this by implementing insertText, and if the text is uppercase, do nothing. With slate-react 0.74.2 and below, this works correctly. But with slate-react 0.75.0 and above, it is broken: the text is inserted into the DOM anyway. However, it is (correctly!) NOT inserted into Slate's document -- this means the DOM and the Slate document are then out of sync, leading to further bugs.

Sandbox

Example: https://codesandbox.io/s/inserttext-should-do-nothing-if-it-returns-wzc647?file=/index.js

Steps
To reproduce the behavior:

1. Go to the sandbox above
2. In the editor, type "X"
3. Note that the character "X" is incorrectly inserted into the DOM
4. Type "x"
5. Note that the previous "X" has disappeared, and an incorrect character has been replaced with "x". (This is presumably due to desynchronization between DOM and Slate document)

Expectation
If my insertText does nothing, nothing should happen.

Environment

• Slate Version: slate-react 0.66.0 and above. slate-react 0.65.3 works. Note that the bug will seem to not be present with Chrome v100+ and slate-react 0.66.0--0.75.0, but this is due to an unrelated bug (Fix chrome and edge three digit version check #4883, as noted by @BitPhinix).
• Operating System: Windows
• Browser: Chrome, Firefox

[jameshfisher]

The diff is pretty small: [email protected]@0.75.0

[jameshfisher]

It looks like this is the only substantial change: #4889

[jameshfisher]

Temporary workaround: instead of doing nothing, make an invisible change. Example: https://codesandbox.io/s/workaround-for-slatejs-bug-inserttext-should-do-nothing-if-it-returns-wzc647?file=/index.js

[jameshfisher]

I don't fully understand what #4889 is doing. I tried reverting that change, but the bug persists. Perhaps it is not the source of this bug, or there are further changes that are causing it. @dylans @zhugexinxin maybe you could help me here?

[jameshfisher]

Okay, it gets weirder ... on Chrome, this breaks between [email protected] and [email protected]. But on Firefox, it breaks between [email protected] and [email protected]! Which again suggests that maybe #4889 is not the source of this bug.

[jameshfisher]

The diff is much larger for the Firefox breakage: [email protected]@0.66.0. Although, like the diff that breaks Chrome, it makes changes to Slate.Transforms.setNodes.

[BitPhinix]

The issue is the native handling here:

slate/packages/slate-react/src/components/editable.tsx

Line 464 in d399437

let native = false

Since slate doesn't preventDefault in all cases to avoid resulting issues with spell correct, doing nothing in insertText results in the default behavior not being prevented and slate not re-rendering/re-mounting the text node thus, the slate state and dom are out of sync.

Definitely a bug, we should always re-render the affected text node in this case.

[jameshfisher]

Aha, thanks @BitPhinix! So #4889 is nothing to do with this; the cause was #4883. With [email protected], my modern Chrome was being identified as "legacy", in which case Slate does preventDefault.

So I suppose the bug has been around for longer.

[jameshfisher]

To confirm this, I downloaded Chrome 99, as it is not affected by the Chrome regex thing, which was masking the real bug.

This time, Chrome v99 agrees with Firefox: the bug was introduced in slate-react 0.66.0. With slate-react 0.66.0, we see the buggy behavior, but with slate-react 0.65.3, it's fine.

[jameshfisher]

slate-react 0.66.0 introduced this "native event" thing in #3888. So the bug has existed ever since this was first added.

[xNarkon]

Any update?

[delijah]

Any progress on this?