Deleting Chinese IME during composition sends the first character to the Terminal #7134

Closed
opened 2026-01-31 00:56:00 +00:00 by claunia · 4 comments
Owner

Originally created by @leonMSFT on GitHub (Mar 24, 2020).

Steps to reproduce

Related to #5054
Start a Chinese IME composition without completing it/selecting the characters e.g. "wei'yuan", then delete the characters.

Expected behavior

There should be no characters left on the screen.

Actual behavior

The letter "w" will appear in the buffer.

Cause

We're receiving a CompositionCompleted event before we receive a TextUpdating event for the final character "w" to be deleted. This causes us to believe that "w" is a completed composition, so we send it to the terminal. We then receive the TextUpdating event right after to tell us to delete the "w", so it disappears from the _inputBuffer.

Originally created by @leonMSFT on GitHub (Mar 24, 2020). # Steps to reproduce Related to #5054 Start a Chinese IME composition without completing it/selecting the characters e.g. "wei'yuan", then delete the characters. # Expected behavior There should be no characters left on the screen. # Actual behavior The letter "w" will appear in the buffer. # Cause We're receiving a `CompositionCompleted` event before we receive a `TextUpdating` event for the final character "w" to be deleted. This causes us to believe that "w" is a completed composition, so we send it to the terminal. We then receive the `TextUpdating` event right after to tell us to delete the "w", so it disappears from the `_inputBuffer`.
Author
Owner

@DHowett-MSFT commented on GitHub (Mar 26, 2020):

Tagging this into v1.x -- feel free to override me

@DHowett-MSFT commented on GitHub (Mar 26, 2020): Tagging this into v1.x -- feel free to override me
Author
Owner

@skyline75489 commented on GitHub (Mar 26, 2020):

As weird as it may seem, the behaviour of WT is actually aligned with stock cmd.exe. This bug also exists there. Exact same bahaviour. Does this mean it is what we actually expect it to be? I'm confused...

@skyline75489 commented on GitHub (Mar 26, 2020): As weird as it may seem, the behaviour of WT is actually aligned with stock `cmd.exe`. This bug also exists there. Exact same bahaviour. Does this mean it is what we actually expect it to be? I'm confused...
Author
Owner

@DHowett-MSFT commented on GitHub (Mar 26, 2020):

For version 1, "works like cmd.exe" will be acceptable. We'd love to do better than cmd.exe, but our deadlines are getting closer every day 😁

@DHowett-MSFT commented on GitHub (Mar 26, 2020): For version 1, "works like cmd.exe" will be acceptable. We'd love to do better than cmd.exe, but our deadlines are getting closer every day :grin:
Author
Owner

@leonMSFT commented on GitHub (Mar 26, 2020):

I'm surprised cmd behaves the same way! It kinda sounds like both Terminal and cmd use the same underlying api, making them both able to repro this bug.

@leonMSFT commented on GitHub (Mar 26, 2020): I'm surprised cmd behaves the same way! It kinda sounds like both Terminal and cmd use the same underlying api, making them both able to repro this bug.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7134