Suggestions on IME composition detection

[NitroRCr]

The issue is somewhat complex, involving several related issues, and it has been around for a while. Let me first explain the overview.

What is IME composition?

In some languages (primarily Chinese, Japanese, and Korean, hereinafter referred to as CJK), text is input through an IME (Input method editor). During the spelling of a word, the keystrokes (letters) pressed by the user are temporarily displayed in the input box, but they are not part of the final user input. They are replaced by the input result once the composition is complete. Therefore, during the composition process, the value of modelValue should not be updated because these characters representing the composition process are meaningless. This is the purpose of IME composition detection: to prevent modelValue updates during the IME composition process.

Current issues with IME composition in Quasar

Quasar implements IME composition detection in q-input and q-select, primarily in use-key-composition.js.

It detects the data of compositionupdate event , and if it contains CJK characters, it sets qComposing to true, which prevents the update of modelValue. The problem is that, in some IMEs, the event's data attribute contains the original key characters and not CJK characters. In such cases, IME composition detection does not work.

Attempts at improvement

PR #17476 modified the detection method to make it consistent with Vue's native v-model detection method, solving this issue.

Specifically, this method does not check character values, and any input between the compositionstart and compositionend events will not trigger an update of modelValue.

However, this PR was later reverted because it introduced other issues. In some versions of the Android AOSP screen keyboard, although English is being input, the keyboard emits composition events, preventing the modelValue from updating promptly. (see #17536) Frankly, I believe this is an issue with the AOSP screen keyboard, as there should be no composition process when typing in English, and it should not emit composition events. Regardless, this issue needs to be avoided.

Further improvements

Since the detection method is consistent with Vue's native v-model, how does Vue avoid this issue? The answer is that Vue has the same problem. When you set v-model on a native input element and test it using the same AOSP screen keyboard, you'll find that the model does not update promptly.

The difference is that for native input, we can directly listen to the input event, which does not have composition detection, and any input triggers immediately. For the aforementioned issue, it can be avoided by listening to the input event. But q-input does not have an input event. This also highlights another current issue: when IME composition detection is in effect, we cannot listen to inputs during the composition process (i.e., we cannot manually disable composition detection, although such a need is very rare).

Naturally, we might think of adding an input event to q-input, which is what PR #17543 aims to achieve. Although its implementation might not be perfect, it is indeed a solution worth considering.

Other improvement solutions

The aforementioned improvement methods (PR #17476 + PR #17543) have the advantage of being consistent with Vue's native v-model and input event behavior, and they can cover all situations requiring IME composition detection. However, the downside is that in some previous scenarios where IME composition was not needed, to avoid the AOSP screen keyboard issue, places using v-model would need to be changed to listen to the input event.

Clearly, there are other methods.

For example, a minor change: instead of checking whether compositionupdate event.data is a CJK character, check whether navigator.language is CJK. This would cover more situations requiring composition detection without other impacts, but the downside is that it still lacks a method to manually disable composition detection.

Or perhaps a better method that I'm not thinking of?

I hope my suggestions can help quasar achieve better IME composition detection.

[jtilford]

Many thanks for putting this together, @NitroRCr. I’m an affected user with most of our client devices operating on impacted versions of Android AOSP.

My intuition here, wrong as it may be, is to add a Boolean property to the component, allowing for enabling or disabling IME composition detection entirely. For backward compatibility, the default condition would maintain current component behavior.

Personally I wouldn’t mind having to add ‘:propName=“false”’ to every instance in my app, since I know about this issue, but that could cause unintended side effects for a lot of Quasar users in these edge cases. I’m not sure about the philosophy here for backward compatibility.