Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tabbed IME fails to insert symbols with a chinese input method #4148

Closed
lhecker opened this issue Jan 8, 2020 · 0 comments · Fixed by #4688
Closed

Tabbed IME fails to insert symbols with a chinese input method #4148

lhecker opened this issue Jan 8, 2020 · 0 comments · Fixed by #4688
Assignees
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@lhecker
Copy link
Member

lhecker commented Jan 8, 2020

Environment

Windows build number: 19041.1
Windows Terminal version (if applicable): `911a9dd`

Steps to reproduce

  • Use a Chinese (Simplified, China) input method (with a Microsoft Pinyin keyboard – the default)
  • Open the tabbed IME using Win.
  • Insert a few symbols from the symbol tab
  • Defocus/Close the IME
  • Bring up the Chinese/Pinyin IME again by pressing any keyboard key
  • Insert a Chinese character

Expected behavior

All characters are inserted instantly into the shell prompt.

Actual behavior

Characters aren't inserted until you defocus/close the IME and bring it up again by pressing a regular keyboard key. Demo

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jan 8, 2020
@DHowett-MSFT DHowett-MSFT added Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Jan 9, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jan 9, 2020
@DHowett-MSFT DHowett-MSFT added this to the Terminal v1.0 milestone Jan 9, 2020
@DHowett-MSFT DHowett-MSFT added the Help Wanted We encourage anyone to jump in on these. label Jan 9, 2020
@zadjii-msft zadjii-msft added the Priority-2 A description (P2) label Jan 22, 2020
@cinnamon-msft cinnamon-msft added v1-Scrubbed Priority-1 A description (P1) and removed Priority-2 A description (P2) labels Jan 23, 2020
@leonMSFT leonMSFT self-assigned this Feb 20, 2020
@ghost ghost added the In-PR This issue has a related PR label Feb 21, 2020
@ghost ghost closed this as completed in #4688 Feb 26, 2020
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Feb 26, 2020
ghost pushed a commit that referenced this issue Feb 26, 2020
## Summary of the Pull Request
Currently, while in IME mode, selections with the Emoji/Kaomoji/Symbol Picker (which is brought up with <kbd>win+.</kbd>) are not displayed until the user starts a new composition. This is due to the fact that we hide the TextBlock when we receive a CompositionCompleted event, and we only show the TextBlock when we receive a CompositionStarted event. Input from the picker does not count as a composition, so we were never showing the text box, even if the symbols were thrown into the inputBuffer. In addition, we weren't receiving CompositionStarted events when we expected to.

We should be showing the TextBlock when we receive _any_ text, so we should make the TextBlock visible inside of `TextUpdatingHandler`. Furthermore, some really helpful discussion in #3745 around wrapping the `NotifyTextChanged` call with a `NotifyFocusLeave` and a `NotifyFocusEnter` allowed the control to much more consistently determine when a CompositionStarted and a CompositionEnded.

I've also went around and replaced casts with saturating casts, and have removed the line that sets the `textBlock.Width()` so that it would automatically set its width. This resolves the issue where while composing a sentence, the textBlock would be too small to contain all the text, so it would be cut off, but the composition is still valid and still able to continue.

## PR Checklist
* [x] Closes #4148
* [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
Tested picking emojis, kaomojis, and symbols with numerous different languages.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants