Bug: Composing Korean is not correctly handled on iOS

[2wheeh]

Lexical version: 0.14.3 (the latest)

Steps To Reproduce

on iOS:

Korean Keyboard inputs don't emit CompositionEvents (any of compositionstart, compositionend, compositionupdate) keeping isComposing as false. That’s same context as keyCode is not 229 on composing Korean on iOS. (Japanese and Chinese seem to behave as expected)

Instead, these Korean inputs are handled in onBeforeInput with deleteContentBackward and insertText of InputType.

For example, when we type ㄱ, ㅏ for 가: The character ㄱ is inserted upon inputting ㄱ. Then, upon ㅏ input, ㄱ is deleted, and 가 is inserted using beforeinput events. During this process, composing is cleared, which is not accessible due to above reason, at least I am not aware of any API could help with this.

on BACKSPACE key input, its default behavior would be to clear composing and delete the character. However, it reaches KEY_BACKSPACE_COMMAND handlers (ref: @lexical/rich-text, @lexical/plain-text) on keyDown, where we prevent the default behavior and call deletion handler. Here, the character is deleted but composing is not cleared due to preventing default.

So this leads to push remnants when next key inputs come:

• #3305

And since it's not handled by Lexical's composition event handlers (onCompositionStart, onCompositionEndEmpl, ...) there may be other effects.

i.e. the lying caret (?) for composing character is not displayed and LexicalEditor._compositionKey is not utilized.

It's not easy to see all the effects since we don't have e2e-ios tests !

Link to code example: can reproduce in playground

The current behavior

https://github.com/facebook/lexical/assets/40269597/e8883eb9-9ca3-479a-b970-376ca0ac8e74

The expected behavior

Korean composition on iOS works well as much as with native browser contenteditable.