2wheeh
commented
2 weeks ago Hi !
The way I see it,
In Safari, the compositionEnd event does not trigger when a Korean consonant is followed by a number or a special character, whereas in Chrome, the compositionEnd event is fired in this scenario.
In both browsers, the following events occurs during composition:
insertCompositionText: when inputting during composingcompositionEnd: when the composition ends
However, in Safari, there are additional events that occur before compositionEnd:
deleteCompositionText: removes the composing characterinsertFromComposition: inserts the composed character at the original composition start position
- Just FYI, these 2 are eliminated from W3C Input Events Level 2 (related PR: https://github.com/w3c/input-events/pull/122)
This is why the key of the textNode is updated here:
https://github.com/facebook/lexical/assets/40269597/933ed2aa-7497-474b-8121-0fd3c03e129f
- deletion and insertion occur at the collapsed position
- the composing character is only textContent
It ends up deleting the textNode and creates a new one with 가, then adds 나 starting new composition cycle.
In Safari, when numbers or special characters follow, leading to the end of composition, it closes composition directly. The character that ends composition comes as separate input from the composition (keyCode is not 229) with insertText event.
In Chrome, the character leading to the end of composition is input as the last input of the composition (keyCode 229). compositionEnd comes after this.
The issue arises in a certain condition where the IME discards the character being composed, which should have been followed by the character ending the composition (such as numbers or special characters, ...).
For instance:
가 => input 1 => 가1 should have been input as the composed result, then composition to be ended.
The issue is 가 => input 1 => 1 (가 disappeared) situation.
Our investigation has led us to believe that the issue occurs when the compositionEnd event is triggered in Chrome, causing $setCompositionKey(null) to be called within Lexical.js.
I think you might guess $setCompositoniKey(null) makes the IME discard that 가 here.
However, $setCompositoniKey(null) is fired after 1 is input instead of 가1 already.
IMO, the issue is not in incorrectly clearing Lexical's composition data but in Chrome IME's composing stack (?) clearing being triggered unexpectedly.
I suspect there might be a trigger during beginUpdate or commitPendingUpdates ...though I couldn't identify what it is.
Additionally, the e.preventDefault in the onBeforeInput event seems to contribute to this problem.
If you have a snippet of a valid workaround, would you mind sharing it?
The narrower condition to reproduce this:
- It happens at the offset 0
- After BACKSPACE or selecting a range
It works correctly after clicking the editor or on the inputs following a new line break on ENTER. Plus, it can happen with either a consonant or a combined alphabet.
https://github.com/facebook/lexical/assets/40269597/490ed328-259b-4829-b695-a53a82c442eb
hyunjaesung
I am currently using Lexical.js as the input system for our project. We have discovered an issue that occurs in the Chrome browser on desktop environments. When a user types a Korean consonant followed by a number or a special character, the consonant disappears, leaving only the number or special character. This behavior differs from a standard browser textarea, where the consonant remains and the number or special character is inserted alongside it.
As a temporary workaround, we have implemented a solution in our project where we create a space before receiving input to avoid this issue. We have identified that this problem arises due to the different handling of the compositionEnd event between Chrome and Safari. In Safari, the compositionEnd event does not trigger when a Korean consonant is followed by a number or a special character, whereas in Chrome, the compositionEnd event is fired in this scenario.
Our investigation has led us to believe that the issue occurs when the compositionEnd event is triggered in Chrome, causing $setCompositionKey(null) to be called within Lexical.js. Additionally, the e.preventDefault in the onBeforeInput event seems to contribute to this problem.
Thank you for your attention to this matter.
Lexical version: 0.13.1 later
Steps To Reproduce
The current behavior
The expected behavior