-
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
[Android/Chrome] AndroidEditable
interfering with IME
#4400
Comments
AndroidEditable
interfering with IMEAndroidEditable
interfering with IME
Slate should not re-render the DOM or change the DOM’s selection if the HTML produced by the IME matches the HTML or selection that Slate would render after the input manager updates the state. |
@Lanny Would you mind sharing your experience after removing AndroidEditable? I am also having composition issues with Korean letters. |
I have more verbose thoughts, but it seems pretty clear to me that fixes made to the editor rarely are also ported to the Android version. I would like to see the Android version provide small extensions as needed to the general editor rather than being a full fork of the relevant files. |
@dylans if fixes rely on input events, there's no way to port those to Android - Android handles input like a circa 2010 browser; the input events there are not trustworthy. Supporting GBoard in particular is quite a wild ride. |
Description
On android, using IME (I used Japanese, the same is reproducible for Korean that I know of, unconfirmed reports from users about accented latin characters) doesn't compose as expected (each keystroke produces at least one entered character, composing a character via multiple keystrokes just doesn't work) and often produces a string of repeated characters. E.g. pressing the "a" key will produce "あ" and composition is finished. Pressing "h" (intending to follow with "a") when attempting to input "は" produces the latin character "h".
Interestingly, changing this line in
slate-react/src/index.ts
:such that
AndroidEditable
is simply not used fixes the issue. No other issues in some brief testing on android, iOS, and OSX were found.Recording
https://user-images.githubusercontent.com/2343714/127573364-eaac1cc6-c73a-411d-97e3-3e7ca194a751.mp4
Sandbox
Reproducible on: https://www.slatejs.org/examples/richtext
Steps
To reproduce the behavior:
Expectation
Multiple keystrokes allows the composition of characters, characters are not repeat-entered
Environment
Context
Happy to open a PR just ripping out the
AndroidEditable
component, but I expect it exists for a reason and such a PR wouldn't be productive. Given everything I tried works fine on Android without usingAndroidEditable
some more context on what problemAndroidEditable
is trying to solve might help me understand where it diverges from regularEditable
and where this bug is.The text was updated successfully, but these errors were encountered: