[Android/Chrome] `AndroidEditable` interfering with IME

[Lanny]

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 @ 354b0092ee7aca951eb48b0a73c886565d4ba0ea
• 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.

[justjake]

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]

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

[dylans]

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]

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