onInput not fired when typing at the start of a contenteditable about slate HOT 4 OPEN

Thanks @user178392143 for verifying. I'll take a look and see if I have any ideas, but I'm mildly pessimistic as this is often an area where fixing one thing breaks three other things.

from slate.

The code in question hasn't changed in 3 years, but was added to work around https://issues.chromium.org/issues/40197599.

It's possible that Chrome recently changed behavior here (as they did break us in an interesting way in Chrome 112 or so).

You'll see at the bottom of the Chrome issue is the mention of

What I would suggest:

• Try the test case in https://issues.chromium.org/issues/40197599 , is this still a bug in Chrome?
• If not, then we can remove the workaround, but need to determine the Chrome version when this behavior changed.
• If still a bug, then I suggest trying to use the workaround suggested.

from slate.

Thanks! As far as I can tell, the Chromium bug still reproduces in Chrome (you can't manage to type at the beginning of the <code> node.)

I gave the inline workaround a try, but it didn't change the results. One thing to note is that the onInput issue occurs equally with inline or block nodes. In my minimal example, it's a block node (a <div>) that we're editing, and with my actual application, it's an inline. With the workaround I saw the same results in both: no onInput fired.

Here's the minimal example, which shows the bug within a <div>:

from slate.

I've come up with a workaround for this. I can't vouch for its total reliability, but you can listen to onDOMBeforeInput and simply save the InputEvent it gives you for later processing, such as in onValueChange. This does mean you have to make your changes to the document after Slate has processed the input, which is probably the better course anyways. This has gotten me unblocked for the time being.

from slate.