fix: iOS Safari Chinese punctuation input not working

[mylukin]

Summary

Fix Chinese punctuation input (，。！？) and emoji not working correctly on iOS Safari.

Problem

Chinese Punctuation

On iOS Safari, Chinese punctuation and spaces are dropped when using IME input. The input events have ev.composed=true but don't go through the composition flow (no compositionstart/compositionend events).

The existing condition (!ev.composed || !this._keyDownSeen) rejects these inputs because:

• ev.composed is true (crossed shadow DOM boundary)
• _keyDownSeen is true (keydown fired before input)

Emoji Duplication

On iOS Safari, emoji input causes duplicates because of timing:

1. compositionend fires → isComposing becomes false
2. input event fires → xterm.js would accept it (first copy)
3. setTimeout in CompositionHelper fires → sends emoji (second copy)

Solution

Replace the condition with two checks:

• !compositionHelper.isComposing - not actively composing
• !compositionHelper.isSendingComposition - no pending setTimeout to send composition

Added public getter isSendingComposition to CompositionHelper to expose the _isSendingComposition state.

This correctly handles all cases:

• ✅ Accepts punctuation input (not composing, not pending)
• ✅ Rejects input during active composition (CompositionHelper handles it)
• ✅ Rejects input when CompositionHelper has pending setTimeout
• ✅ Prevents emoji duplication

Changes

1. src/browser/input/CompositionHelper.ts: Added isSendingComposition getter
2. src/browser/Types.ts: Added isSendingComposition to ICompositionHelper interface
3. src/browser/CoreBrowserTerminal.ts: Updated condition in _inputEvent()

Testing

Tested on iOS Safari with:

• ✅ Chinese punctuation: ，。！？：；""''
• ✅ Spaces after Chinese characters
• ✅ Emoji (no duplication)
• ✅ Regular English input
• ✅ CJK character input via IME

Related Issues

Fixes #3070
Fixes #4486

[iven]

Will this fix punctuation input in other browsers (like electron)?

[mylukin]

Will this fix punctuation input in other browsers (like electron)?

I only tested it on Safari.

[Tyriar]

I don't have an iOS device and punctuation seems to work fine for me on latest on macOS/Safari. I recently discovered some quirks around composition events in #5704 on Safari but those affected desktop as well. Do you know of any way to reproduce this on desktop?

[pursuemoon]

I don't have an iOS device and punctuation seems to work fine for me on latest on macOS/Safari. I recently discovered some quirks around composition events in #5704 on Safari but those affected desktop as well. Do you know of any way to reproduce this on desktop?

Perhaps I understand why you can't reproduce the problem.

Some Chinese input methods used in China (such as Sogou) don't include keyCode=229 when inputting punctuation marks like "。" and "，". This causes xterm.js to not recognize it as a text composition event, triggering the default keystroke behavior and outputting English punctuation marks like "." and ",". This is why many people say CJK punctuation marks aren't being output correctly.

MacOS's built-in input method doesn't exhibit this behavior. Therefore, you can't reproduce the problem.

Considering that KeyboardEvent.keyCode has been marked as deprecated, perhaps xterm.js should optimize this. Otherwise downstream applications will need to do repeative work to fix it like VSCode (microsoft/vscode#320525).