-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Firefox does not fire beforeinput
events
#3185
Comments
This comment has been minimized.
This comment has been minimized.
https://bugzilla.mozilla.org/show_bug.cgi?id=970802 and https://bugzilla.mozilla.org/show_bug.cgi?id=1449831 have been marked as fixed 👍 |
+1 I force "true" here
|
This comment has been minimized.
This comment has been minimized.
Doesn't work on Firefox 80. It actually disables the fallback and ends up not firing any events when you spellcheck, this makes it look like it works but instead what you get is the real DOM not synchronizing with slate internal representation (doesn't What I did instead was to add a special fallback mechanism using the Edit: Seems like the feature is available in nightly since 74 but has to be enabled by the user with the preference (dom.input_events.beforeinput.enabled) - https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#HTML_DOM_API |
Yes, I want plz ;) |
You shouldn't detect by UA, instead detect feature like below.
|
Firefox does not currently support the
beforeinput
event, which Slate uses under the covers to be notified whenever the user triggers an input into the editor (inserts, deletes, cuts, pastes, drops, etc.). Thesebeforeinput
events are cancellable and we use them to then do the Slate-equivalent of whatever the event was.Right now we hack around this for Firefox and handle some of the common input cases. However, there's only so much we can do. And input events like
formatBold
, orinsertFromComposition
are hard to polyfill. (There might be ways to improve our existing ones, if you see them please PR!)This is also the reason we disable
autoCorrect
andspellCheck
in Firefox on thecontenteditable
element, since we have no easy way of determining when those changes occur.Here are the bug reports… (please vote for and follow them!)
Once these are supported Firefox will get improved editing support (autocorrect, spellcheck, IME composition, B/U/I toolbars, etc.). And we'll be able to reduce bundle size for everyone by removing the current Firefox-specific hacks.
The text was updated successfully, but these errors were encountered: