Sogou IME candidate/composition UI invisible in Windows Terminal Stable 1.23.2512.16003 (Preview 1.24 works) #23896

@clapat-bb commented on GitHub (Dec 22, 2025):

Haha, when I encountered this problem, I updated to the latest Sogou Input Method and suspected it was a font setting issue from this morning, but after verifying all of these, the problem persisted. I've temporarily switched to WeChat Input Method now; the green interface is quite eye-friendly.

@clapat-bb commented on GitHub (Dec 22, 2025): Haha, when I encountered this problem, I updated to the latest Sogou Input Method and suspected it was a font setting issue from this morning, but after verifying all of these, the problem persisted. I've temporarily switched to WeChat Input Method now; the green interface is quite eye-friendly.

claunia commented

@o87110 commented on GitHub (Dec 22, 2025):

iFlytek input method also has this problem.

@o87110 commented on GitHub (Dec 22, 2025): iFlytek input method also has this problem.

claunia commented

@lhecker commented on GitHub (Dec 22, 2025):

If I had to take a guess, I think this is another variant of a bug we fixed in #19046 and #19117. It was first released in v1.24 and also backported to v1.23.12102.0. It should be part of the version you're using.

The problem now is that our IME integration is identical between v1.23 and v1.24, so why does one work and not the other? The diff is completely empty:

git diff origin/release-1.23..origin/release-1.24 src/tsf/Implementation.cpp

This is very weird.

Side note:

The issue back then was actually a bug in QQPinjin itself, and other similar IME. They specify that they want a custom foreground color (TF_CT_COLORREF) and the default background color (TF_CT_NONE). Then, they set the custom foreground color to #000000 black. Since your terminal background is also black, you then couldn't see the IME text anymore. This sounds very similar to your issue.

(If you're wondering what an IME should do instead: They should just not specify any color at all! Simply set both crText|crBk.type to TF_CT_NONE. And if an IME does want a custom color, they should always specify colors for crText, crBk, and crLine at the same time, to ensure that there's no mixups with the application colors.)

@lhecker commented on GitHub (Dec 22, 2025): If I had to take a guess, I think this is another variant of a bug we fixed in #19046 and #19117. It was first released in v1.24 and also backported to [v1.23.12102.0](https://github.com/microsoft/terminal/releases/tag/v1.23.12102.0). It should be part of the version you're using. The problem now is that our IME integration is identical between v1.23 and v1.24, so why does one work and not the other? The diff is completely empty: ```sh git diff origin/release-1.23..origin/release-1.24 src/tsf/Implementation.cpp ``` This is very weird. --- Side note: The issue back then was actually a bug in QQPinjin itself, and other similar IME. They specify that they want a custom foreground color (`TF_CT_COLORREF`) and the default background color (`TF_CT_NONE`). Then, they set the custom foreground color to `#000000` black. Since your terminal background is also black, you then couldn't see the IME text anymore. This sounds very similar to your issue. (If you're wondering what an IME should do instead: They should just not specify any color at all! Simply set both `crText|crBk.type` to `TF_CT_NONE`. And if an IME does want a custom color, they should always specify colors for `crText`, `crBk`, and `crLine` at the same time, to ensure that there's no mixups with the application colors.)

claunia commented

@lhecker commented on GitHub (Dec 22, 2025):

Ah now that I re-read your issue description, I realize I misunderstood your issue. I thought you meant the completion text, but you meant the candidate window of course. Perhaps I need a second coffee? 😅 I apologize for that. 😢

Unfortunately, for that I can't immediately think of a reason... Our IME integration (TSF) between v1.23 and v1.24 is identical and the window management contains barely 60 lines of changes (most of which is completely unrelated). There's lots of changes in the terminal UI / control code, but that should have no effect on an IME, unless it integrated itself with our UI code. (TSF gives the window coordinates directly to the IME so there should be no need for that.)

We're planning to release v1.24 as the next stable version very soon. So, it may not be worth it to investigate this further. 🙈

@lhecker commented on GitHub (Dec 22, 2025): Ah now that I re-read your issue description, I realize I misunderstood your issue. I thought you meant the completion text, but you meant the candidate window of course. Perhaps I need a second coffee? 😅 I apologize for that. 😢 Unfortunately, for that I can't immediately think of a reason... Our IME integration (TSF) between v1.23 and v1.24 is identical and the window management contains barely 60 lines of changes (most of which is completely unrelated). There's lots of changes in the terminal UI / control code, but that should have no effect on an IME, unless it integrated itself with our UI code. (TSF gives the window coordinates directly to the IME so there should be no need for that.) We're planning to release v1.24 as the next stable version very soon. So, it may not be worth it to investigate this further. 🙈

claunia commented

@MonchiLin commented on GitHub (Dec 22, 2025):

Based on @lhecker’s reply, I installed version 1.24 using the following command, and Sogou IME now works correctly:

winget install --id Microsoft.WindowsTerminal.Preview -e

@MonchiLin commented on GitHub (Dec 22, 2025): Based on @lhecker’s reply, I installed version 1.24 using the following command, and Sogou IME now works correctly: ```powershell winget install --id Microsoft.WindowsTerminal.Preview -e ```

claunia commented

@elvismile commented on GitHub (Dec 23, 2025):

I encountered the same problem after updating to version 1.23.13503.0. Microsoft Pinyin input works fine for Chinese characters, but Sogou does not display the candidate box when inputting Chinese characters.

@elvismile commented on GitHub (Dec 23, 2025): I encountered the same problem after updating to version 1.23.13503.0. Microsoft Pinyin input works fine for Chinese characters, but Sogou does not display the candidate box when inputting Chinese characters.

claunia commented

@Fitmtfk commented on GitHub (Dec 23, 2025):

I have some more information about this bug.My regedit has the same problem.I have two device runing Win11 23H2 but different subversion(22631.6199 and 22631.4112)
22631.6199:Windows Terminal(1.23.13503.0),regedit(10.0.22621.5262) all broken
22631.4112:Windows Terminal(1.21.10351.0),regedit(10.0.22621.4111) all fine
and i try to copy regedit(10.0.22621.4111) with mui to 22631.6199 it works well.
Perhaps there is a causal relationship between these two problems

@Fitmtfk commented on GitHub (Dec 23, 2025): I have some more information about this bug.My regedit has the same problem.I have two device runing Win11 23H2 but different subversion(22631.6199 and 22631.4112) 22631.6199:Windows Terminal(1.23.13503.0),regedit(10.0.22621.5262) all broken 22631.4112:Windows Terminal(1.21.10351.0),regedit(10.0.22621.4111) all fine and i try to copy regedit(10.0.22621.4111) with mui to 22631.6199 it works well. Perhaps there is a causal relationship between these two problems

claunia commented

@showyourlucky commented on GitHub (Dec 23, 2025):

I resolved this issue using version 1.24.2812
download link: https://github.com/microsoft/terminal/releases/download/v1.24.2812.0/Microsoft.WindowsTerminalPreview_1.24.2812.0_x64.zip

@showyourlucky commented on GitHub (Dec 23, 2025): I resolved this issue using version 1.24.2812 download link: https://github.com/microsoft/terminal/releases/download/v1.24.2812.0/Microsoft.WindowsTerminalPreview_1.24.2812.0_x64.zip

claunia commented

@eromoe commented on GitHub (Dec 25, 2025):

same problem

@eromoe commented on GitHub (Dec 25, 2025): same problem

claunia commented

@fengyichui commented on GitHub (Dec 26, 2025):

same problem

@fengyichui commented on GitHub (Dec 26, 2025): same problem

claunia commented

@airborne007 commented on GitHub (Dec 26, 2025):

version: 1.23.13503.0 also has the same problem

@airborne007 commented on GitHub (Dec 26, 2025): version: 1.23.13503.0 also has the same problem

claunia commented

@zscv commented on GitHub (Dec 27, 2025):

I've been watching the new version like it's a part-time job every day, but nothing's happening. 😂
I've decided to revert to the previous version. If you have the same problem, you can do the following:

Uninstall the "bad" version:
winget uninstall --id Microsoft.WindowsTerminal
Go back to the "good" version(eg., v1.23.12811.0)：
winget install --id Microsoft.WindowsTerminal --version 1.23.12811.0

@zscv commented on GitHub (Dec 27, 2025): I've been watching the new version like it's a part-time job every day, but nothing's happening. 😂 I've decided to revert to the previous version. If you have the same problem, you can do the following: 1. Uninstall the "bad" version: `winget uninstall --id Microsoft.WindowsTerminal` 2. Go back to the "good" version(eg., v1.23.12811.0)： `winget install --id Microsoft.WindowsTerminal --version 1.23.12811.0`

claunia commented

@Fitmtfk commented on GitHub (Jan 2, 2026):

I have some more information about this bug.My regedit has the same problem.I have two device runing Win11 23H2 but different subversion(22631.6199 and 22631.4112) 22631.6199:Windows Terminal(1.23.13503.0),regedit(10.0.22621.5262) all broken 22631.4112:Windows Terminal(1.21.10351.0),regedit(10.0.22621.4111) all fine and i try to copy regedit(10.0.22621.4111) with mui to 22631.6199 it works well. Perhaps there is a causal relationship between these two problems

may be it was fixed by sogou？
wt version：1.23.13503.0
sogou version：15.12.0.2855 compiled time: Dec 26 2025 21:11:17
but the problem still exsist in regedit

@Fitmtfk commented on GitHub (Jan 2, 2026): > I have some more information about this bug.My regedit has the same problem.I have two device runing Win11 23H2 but different subversion(22631.6199 and 22631.4112) 22631.6199:Windows Terminal(1.23.13503.0),regedit(10.0.22621.5262) all broken 22631.4112:Windows Terminal(1.21.10351.0),regedit(10.0.22621.4111) all fine and i try to copy regedit(10.0.22621.4111) with mui to 22631.6199 it works well. Perhaps there is a causal relationship between these two problems may be it was fixed by sogou？ wt version：1.23.13503.0 sogou version：15.12.0.2855 compiled time: Dec 26 2025 21:11:17 but the problem still exsist in regedit

claunia commented

@lhecker commented on GitHub (Jan 12, 2026):

may be it was fixed by sogou?
[...]
sogou version：15.12.0.2855 compiled time: Dec 26 2025 21:11:17

Can someone else confirm whether the latest version of Sogou fixes the issue with Windows Terminal 1.23? I unfortunately cannot easily use that IME to test it myself.

@lhecker commented on GitHub (Jan 12, 2026): > may be it was fixed by sogou? > [...] > sogou version：15.12.0.2855 compiled time: Dec 26 2025 21:11:17 Can someone else confirm whether the latest version of Sogou fixes the issue with Windows Terminal 1.23? I unfortunately cannot easily use that IME to test it myself.

claunia commented

@lhecker commented on GitHub (Jan 12, 2026):

The most likely cause for this regression was https://github.com/microsoft/terminal/pull/19584 which added the following 3 TSF flags (TSF is the Windows platform for IMEs):

TF_TMAE_UIELEMENTENABLEDONLY: TSF activates only text services that are categorized as GUID_TFCAT_TIPCAP_UIELEMENTENABLED.
TF_TMAE_NOACTIVATETIP + TF_TMAE_NOACTIVATEKEYBOARDLAYOUT: TSF does not sync the current keyboard layout. The keyboard layout will be adjusted when the calling thread gets focus. = Faster startup.

My guess would be that Sogou IME doesn't set GUID_TFCAT_TIPCAP_UIELEMENTENABLED, but perhaps it's the other two that cause some weird interaction.

@lhecker commented on GitHub (Jan 12, 2026): The most likely cause for this regression was https://github.com/microsoft/terminal/pull/19584 which added the following 3 TSF flags (TSF is the Windows platform for IMEs): - `TF_TMAE_UIELEMENTENABLEDONLY`: TSF activates only text services that are categorized as `GUID_TFCAT_TIPCAP_UIELEMENTENABLED`. - `TF_TMAE_NOACTIVATETIP` + `TF_TMAE_NOACTIVATEKEYBOARDLAYOUT`: TSF does not sync the current keyboard layout. The keyboard layout will be adjusted when the calling thread gets focus. = Faster startup. My guess would be that Sogou IME doesn't set `GUID_TFCAT_TIPCAP_UIELEMENTENABLED`, but perhaps it's the other two that cause some weird interaction.

claunia commented

@nathancorvussolis commented on GitHub (Jan 13, 2026):

TF_TMAE_UIELEMENTENABLEDONLY or TF_TMF_UIELEMENTENABLEDONLY, and GUID_TFCAT_TIPCAP_UIELEMENTENABLED are used in UILess Mode.

UILess Mode Overview - Win32 apps | Microsoft Learn
https://learn.microsoft.com/en-us/windows/win32/tsf/uiless-mode-overview

The application draws the UI by itself in UILess Mode.
For example, previous version of Japanese IME on legacy console shows a candidate window at last line.

If applications do not implement ITfUIElementSink, I think there is no need to declare TF_TMAE_UIELEMENTENABLEDONLY.

TIPs should determine whether it is in UILless mode using ITFUIElementMgr::BeginUIElement method, but some IMEs (like CorvusSKK and perhaps others) uses inappropriately the flags obtained with ITfThreadMgrEx::ActivateEx method or ITfThreadMgrEx::GetActiveFlags method.

@nathancorvussolis commented on GitHub (Jan 13, 2026): `TF_TMAE_UIELEMENTENABLEDONLY` or `TF_TMF_UIELEMENTENABLEDONLY`, and `GUID_TFCAT_TIPCAP_UIELEMENTENABLED` are used in UILess Mode. UILess Mode Overview - Win32 apps | Microsoft Learn https://learn.microsoft.com/en-us/windows/win32/tsf/uiless-mode-overview The application draws the UI by itself in UILess Mode. For example, previous version of Japanese IME on legacy console shows a candidate window at last line. <img width="515" height="179" alt="Image" src="https://github.com/user-attachments/assets/945c4aa4-bacf-4d49-acfe-470caf469123" /> If applications do not implement ITfUIElementSink, I think there is no need to declare `TF_TMAE_UIELEMENTENABLEDONLY`. TIPs should determine whether it is in UILless mode using ITFUIElementMgr::BeginUIElement method, but some IMEs (like CorvusSKK and perhaps others) uses inappropriately the flags obtained with ITfThreadMgrEx::ActivateEx method or ITfThreadMgrEx::GetActiveFlags method.

claunia commented