A couple of problems with core plugin onBeforeInput

While investigating IME bugs, I came across a few problems with onBeforeInput in the core plugin:

1. Is it assumed here that e.data will contain a single character?

https://github.com/ianstormtaylor/slate/blob/239d97fcad6d097d564674846a08924e78d2a503/src/plugins/core.js#L89-L98

In the case of a composition event, onBeforeInput will receive the entire composed string in e.data just before calling the compositionend event, so instantiating a Character with a multiple-char string may break somewhere. (At fist impression, seems the list insertion works either way)

1. I understand this line should mimic what a native insertion would be?

https://github.com/ianstormtaylor/slate/blob/239d97fcad6d097d564674846a08924e78d2a503/src/plugins/core.js#L100

If that’s the case, it should take the selection into consideration, since you may be actually replacing some characters in the process.

This is all I have for now in regards to inserting composed words, I’ll keep investigating — is there any other place that assumes e.data is a single char but then ends up pushing a multi-character string into the state? That may be the source of some of the problems we currently have with IMEs.

Right now I reckon these are causing:

1. Unnecessarily using a non-native insertion when it could have been native, due to mismatch between computing “native” outcome vs. “synthetic” outcome
2. Noticing that when overwriting text with a composed word, the outcome of the “synthetic” action is not accurate (selection is out of sync in the meantime), but the “native” one is, allowing a native insertion might fix some bugs.

[danburzo]

Hi, sorry for the hiatus — I’m back on the problem. I noticed the recent merge that removed isNative, I’d need to get back to speed with the problem and see how it impacts (in my previous tests, disabling isNative did not have a major impact on IME problems unfortunately).

[davidbonnet]

Thanks for your insights @danburzo:

• Yes, before changing the content in onBeforeInput, the current selection must be considered.
• Yes, monitoring the sequence of input events is the right approach, IMHO.
• Although interesting to check, I don’t think it is necessary to compare between sequences of React’s SyntheticEvent and DOMEvents, since this would be a React issue, not a Slate one.

Context

• The Input Method Editor (IME) API enables standard keyboards to input characters that are not directly represented on the keyboard itself, which occurs when writing in Chinese, Japanese, or Korean.
• Lately, the IME API is used on Android to also input suggestions in other languages.
• If input suggestions are disabled, normal keyboard events are issued and Slate works fine.

Proposed approach

1. Monitor sequences of events (with tools like http://danburzo.github.io/input-methods or https://optimdata.github.io/slate/#/mobile as shown in the screenshot below).
2. Define input scenarios that would generate various sequences of events: typing a word, typing a word and choosing a suggestion, deleting characters, deleting a range of characters when long-pressing, etc…
3. For each scenario, record the SyntheticEvent sequences and the resulting HTML on different OS versions (Android 4.0, 4.1, 4.4, 5.0, 6.0, 7.0, 8.0, and iOS).
4. Write tests that execute these event sequences an compare the output to the expected one. In particular, tests such as the ones for the core plugin could be used.

The source code of the event watcher is available in this fork.