fix(chat): ignore Enter key while IME is composing

[Hodokami]

Summary

I noticed this while using Cloudflare OS with a Japanese IME.

The chat composer sent a message on every unmodified Enter press, including the Enter key used to confirm an IME composition. This caused accidental sends while the user was still converting text.

Change

Track the IME composition state using compositionstart and compositionend on the composer textarea, and ignore Enter keydown events while isComposing is true. Also check event.nativeEvent.isComposing for environments where the compositionend/event ordering differs.

Verification

• pnpm lint passes
• pnpm build passes
• pnpm test passes
• Confirmed locally that pressing Enter to confirm a Japanese IME conversion no longer sends the message.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Hodokami]

I have read the CLA Document and I hereby sign the CLA

[kikuchy]

I can confirm that this issue is reproducible on macOS with Arc Browser when using a Japanese IME. Pressing Enter to confirm the current conversion submits the message unexpectedly.

Japanese users are looking forward to seeing this fix merged. Thank you for working on it!

[yusugomori]

Thanks for working on this — I reproduced the same Japanese IME issue and found one Safari/WebKit edge case that may be worth covering before merge.

WebKit bug 165004 documents that Safari can dispatch compositionend before the Enter keydown used to confirm the composition. By the time the key handler runs, both React composition state and nativeEvent.isComposing can therefore be false; keyCode === 229 is the practical fallback for that ordering.

It may also be safer to put the IME guard at the very start of onKeyDown, before the slash-command picker and other custom keyboard handling, so the IME retains the confirmation Enter in every composer state.

I implemented and tested that variant here: yusugomori@be546a9. It covers active isComposing, the Safari 229 fallback, and an ordinary Enter that must remain available for sending.

I won't open a duplicate PR; please feel free to incorporate any of that implementation or its tests into this one.

[kote2kote]

Thank you for this fix — I hit the same bug with a Japanese IME and didn't spot this PR before opening #73, which overlaps with it.

One thing from #73 that may be useful here regardless of which PR lands: it adds the keyCode === 229 fallback for the Safari/WebKit ordering issue mentioned above, and applies the same guard to the chat list rename input and chat title edit input, which have the same bug. Happy to close #73 in favor of this one if the maintainers prefer — just flagging the complementary pieces so they don't get lost.

[kentonv]

Hi @Hodokami,

Apologies but, per our contributing guide, we prefer not to receive external pull requests. We prefer instead to receive issue reports, which we can then direct our own agents to solve. Could you please file an issue instead?