-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
onInput not fired when typing at the start of a contenteditable #5603
Comments
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 slate/site/examples/inlines.tsx Lines 220 to 231 in 1d8010b
What I would suggest:
|
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 I gave the inline workaround a try, but it didn't change the results. One thing to note is that the Here's the minimal example, which shows the bug within a slate-noinput-div-block-element-with-workaround.mp4 |
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. |
I've come up with a workaround for this. I can't vouch for its total reliability, but you can listen to |
Description
In Slate 0.101.5 and Slate-react 0.101.5, a character typed at the start (i.e. offset 0) of a
contenteditable
does not produce anonInput
event.As far as I can tell, this is due to the check in
onDOMBeforeInput
at:slate/packages/slate-react/src/components/editable.tsx
Lines 516 to 519 in b04b7e0
This is part of the conditional looking for native
insertText
events. When the cursor is at offset 0, this fails, and the event is not flagged asnative
(though it is a native event), causingevent.preventDefault()
to get called at:slate/packages/slate-react/src/components/editable.tsx
Lines 606 to 608 in b04b7e0
That prevents
onInput
from firing.I think this seems unintentional? The linked Chrome issue in that comment seems to be discussing a similar but unrelated issue with cursor position restoration. It looks like the check that works around that bug is what's causing the issue I'm seeing.
Recording
In Chrome 121.0.6167.86, 64-bit, on Windows 11. I've added event handlers logging
onDOMBeforeInput
andonInput
, and show the difference between typing in the middle of the text and at the beginning.slate-0-101-5-no-oninput.mp4
Sandbox
I apologize, but I haven't been able to get JSFiddle working with Slate 0.101.5. If someone knows how to set that up, then https://jsfiddle.net/4wgy3j0x/1/ will repro the bug. (All that's needed is the default example with event handlers to show that
onInput
isn't firing.)Steps
To reproduce the behavior:
onDOMBeforeInput
andonInput
fire.)onDOMBeforeInput
fires.)Expectation
I would expect
onInput
to fire when typing a character at any cursor position in thecontenteditable
.Environment
Context
This is for a change tracking feature that requires me to add marker elements to the document delimiting runs of inserted text when the user types. Thus I'm looking for an event where I can see that the user' s typed a character, and modify the document from there.
onInput
seems like the best candidate, but then I ran into this issue. (onDOMBeforeInput
does not work to modify the document, because after the handler runs it will restore the selection to a previously-saved value that is, by then, invalid.) Any workarounds welcome!The text was updated successfully, but these errors were encountered: