Skip to content
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

Open
Lanny opened this issue Jul 29, 2021 · 4 comments
Open

[Android/Chrome] AndroidEditable interfering with IME #4400

Lanny opened this issue Jul 29, 2021 · 4 comments

Comments

@Lanny
Copy link

Lanny commented Jul 29, 2021

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:

- export const Editable = IS_ANDROID ? AndroidEditable : DefaultEditable
+ export const Editable = false ? AndroidEditable : DefaultEditable

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:

  1. Go to https://www.slatejs.org/examples/richtext
  2. In Japanese IME mode, attempt to compose the character "は" (Press "h", then "a")
  3. Observe only "h" is produced, multiple times

Expectation
Multiple keystrokes allows the composition of characters, characters are not repeat-entered

Environment

  • Slate Version: main @ 354b009
  • Operating System: Android 11
  • Browser: Chrome 92.0.4515.115

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 using AndroidEditable some more context on what problem AndroidEditable is trying to solve might help me understand where it diverges from regular Editable and where this bug is.

@Lanny Lanny changed the title AndroidEditable interfering with IME [Android/Chrome] AndroidEditable interfering with IME Jul 29, 2021
@justjake
Copy link

justjake commented Nov 10, 2021

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.

@AkromDev
Copy link

@Lanny Would you mind sharing your experience after removing AndroidEditable? I am also having composition issues with Korean letters.

@dylans
Copy link
Collaborator

dylans commented Nov 26, 2021

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.

@justjake
Copy link

justjake commented Dec 3, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants