Deleting Chinese IME during composition sends the first character to the Terminal #5110
Labels
Area-Input
Related to input processing (key presses, mouse, etc.)
Area-TerminalControl
Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)
In-PR
This issue has a related PR
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Needs-Tag-Fix
Doesn't match tag requirements
Priority-2
A description (P2)
Product-Terminal
The new Windows Terminal.
Milestone
Comments
ghost
added
Needs-Triage
leonMSFT
changed the title
leonMSFT
added
Area-Input
3 tasks
leonMSFT
changed the title
ghost
pushed a commit
that referenced
this issue
Mar 25, 2020
## Summary of the Pull Request This PR fixes an out of bounds access when deleting composition during Chinese IME. What's happening is that we're receiving a CompositionCompleted before receiving the TextUpdate to tell us to delete the last character in the composition. This creates two problems for us: 1. The final character gets sent to the Terminal when it should have been deleted. 2. `_activeTextStart` gets set to `_inputBuffer.length()` when sending the character to the terminal, so when the `TextUpdate` comes right after the `CompositionCompleted` event, `_activeTextStart` is out of sync. This PR fixes the second issue, by updating `_activeTextStart` during a `TextUpdate` in case we run into this issue. The first issue is trickier to resolve since we assume that if the text server api tells us a composition is completed, we should send what we have. It'll be tracked here: #5110. At the very least, this PR will let users continue to type in Chinese IME without it breaking, but it will still be annoying to see the first letter of your composition reappear after deleting it. ## PR Checklist * [x] Closes #5054 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed ## Validation Steps Performed Play around with Chinese IME deleting and composing, and play around with Korean and Japanese IME to see that it still works as expected.
DHowett-MSFT
added
Priority-2
|
Tagging this into v1.x -- feel free to override me |
|
As weird as it may seem, the behaviour of WT is actually aligned with stock |
|
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 😁 |
|
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. |
Closed
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 18, 2024
Next in the popular series of minor refactorings: Out with the old, in with the new! This PR removes all of the existing TSF code, both for conhost and Windows Terminal. conhost's TSF implementation was awful: It allocated an entire text buffer _per line_ of input. Additionally, its implementation spanned a whopping 40 files and almost 5000 lines of code. Windows Terminal's implementation was absolutely fine in comparison, but it was user unfriendly due to two reasons: Its usage of the `CoreTextServices` WinRT API indirectly meant that it used a non-transitory TSF document, which is not the right choice for a terminal. A `TF_SS_TRANSITORY` document (-context) indicates to TSF that it cannot undo a previously completed composition which is exactly what we need: Once composition has completed we send the result to the shell and we cannot undo this later on. The WinRT API does not allow us to use `TF_SS_TRANSITORY` and so it's unsuitable for our application. Additionally, the implementation used XAML to render the composition instead of being part of our text renderer, which resulted in the text looking weird and hard to read. The new implementation spans just 8 files and is ~1000 lines which should make it significantly easier to maintain. The architecture is not particularly great, but it's certainly better than what we had. The implementation is almost entirely identical between both conhost and Windows Terminal and thus they both also behave identical. It fixes an uncountable number of subtle bugs in the conhost TSF implementation, as it failed to check for status codes after calls. It also adds several new features, like support for wavy underlines (as used by the Japanese IME), dashed underlines (the default for various languages now, like Vietnamese), colored underlines, colored foreground/background controlled by the IME, and more! I have tried to replicate the following issues and have a high confidence that they're resolved now: Closes #1304 Closes #3730 Closes #4052 Closes #5007 (as it is not applicable anymore) Closes #5110 Closes #6186 Closes #6192 Closes #13805 Closes #14349 Closes #14407 Closes #16180 For the following issues I'm not entirely sure if it'll fix it, but I suspect it's somewhat likely: #13681 #16305 #16817 Lastly, there's one remaining bug that I don't know how to resolve. However, that issue also plagues conhost and Windows Terminal right now, so it's at least not a regression: * Press Win+. (emoji picker) and close it * Move the window around * Press Win+. This will open the emoji picker at the old window location. It also occurs when the cursor moves within the window. While this is super annoying, I could not find a way to fix it. ## Validation Steps Performed * See the above closed issues * Use Vietnamese Telex and type "xin choaf" Results in "xin chào" ✅ * Use the MS Japanese IME and press Alt+` Toggles between the last 2 modes ✅ * Use the MS Japanese IME, type "kyouhaishaheiku", and press Space * The text is converted, underlined and the first part is doubly underlined ✅ * Left/Right moves between the 3 segments ✅ * Home/End moves between start/end ✅ * Esc puts a wavy line under the current segment ✅ * Use the Korean IME, type "gksgks" This results in "한한" ✅ * Use the Korean IME, type "gks", and press Right Ctrl Opens a popup which allows you to navigate with Arrow/Tab keys ✅
microsoft-github-policy-service
bot
added
the
Needs-Tag-Fix
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
CompositionCompletedevent before we receive aTextUpdatingevent 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 theTextUpdatingevent right after to tell us to delete the "w", so it disappears from the_inputBuffer.The text was updated successfully, but these errors were encountered: