When in Japanese input, 'enter' should not immediately send the message

[dvcrn]

Describe the bug

In Japanese IME, you typically type text, then hit enter to "commit" the correct Kanji. For example, if I type テスト then it will be underlined until I hit 'enter', in effect confirming that I've finished writing and picked the correct Kanji/characters

Cinny binds to enter, so even though I am not done typing and only committed a word, as soon as I hit enter, Cinny sends the message

It's a very common problem when using onkeyup as listener, eg: https://stackoverflow.com/questions/46812908/enter-keyup-event-in-japanese-input

Reproduction

No response

Expected behavior

No response

Platform and versions

macOS Desktop 4.2.3, macOS 15.2

Additional context

No response

[kfiven]

There's an option to change the behavior of Enter in settings, have you tried that?

[dvcrn]

Yes that works, but it's not the expected behavior. Hitting enter when in Japanese (or other asian) IME should not trigger sending of a message, since it will send an incomplete sentence/word

[programmablereya]

I haven't encountered this yet, but I can definitely speak to this being undesired, buggy behavior.

Between compositionstart and compositionend events - i.e., when KeyboardEvent.isComposing is true, the keydown and keyup events should be ignored by the editor. This is because at that time, the IME is composing the user's next character(s). While in an IME, the browser ignores all keystrokes, even ones with modifiers; Ctrl+T does not open a new tab, Ctrl+W does not close the current tab, Tab does not navigate the focus to the next element, etc. The only keystrokes that are expected to still function are system-wide keystrokes like Alt+F4.

The keydown events are still delivered to the browser (and thus to your code), but they should be ignored; they are fired primarily for you to be able to do things like have your code respond to the length of the partially-composed text, not to be treated as input directly to you. See the guidance here for another source on how to handle keydown events with IMEs.

You can experience an IME and see how it behaves in most programs by installing an input language with one (e.g., Japanese) and switching to it in your input selector. Or, if you're using GNOME, you can press Ctrl+Shift+E to enter an IME for inputting special characters (particularly emoji, but it lists all Unicode characters).

[programmablereya]

Okay - it looks like the issue is specifically that Safari sends compositionend before sending the Enter keydown event, whereas other browsers send it between keydown and keyup. isComposing is just a helper property to avoid having to capture compositionstart and compositionend yourself, so it will also be affected by this.

And it's not guaranteed that the next keydown/keyup after compositionend is the keypress that ended composition, even in Safari; there are ways to end composition that don't require a keypress! (e.g., clicking a suggestion with the mouse or a touch input)

However, it does look like Safari respects the idea that keyCode must be 229 during composition (but not that key must be Unidentified...). Which should let us intercept this.

I'll adapt my in-progress patch to make use of this information.

[programmablereya]

@dvcrn - could you build the PR version and test that it does, in fact, work around the problem here?

[dvcrn]

Tested your PR and it fixes the issues, however there are a few build errors, I'll comment in the PR