Chromium

Here are some clues: https://stackoverflow.com/questions/53058696/keydown-event-not-triggered-for-textbox-when-setting-ime-as-japanese And also confirmed by logging, when the TSF is focused, it will consume all the window messages, and will dispatch within HandlePeekMessage later.

Normally, when I breakpoint at OnKeyTraceDown, this will return true with a KEYDOWN event. However when triggered the bug, this will return false and no more MOUSE/KEYBOARD event will send to this UI thread unless press Windows key or change IME.

Related: https://groups.google.com/g/wx-dev/c/Hemc3N-OQ0c?pli=1

100% Reproduce:

1. Install Microsoft Chinese IME (Pinyin)
2. Change display DPI ratio to 150%
3. Open any chromium based app, find a textarea, for example, https://textarea.online
4. Use Chinese IME type anything for a while
5. Minimize the window (Very important!)
6. Login into this computer through RDP, with DPI ratio set to 100%
7. Open the window and try typing
8. The whole window freeze
9. (until you press something like Windows key, or AltTab, and try switching the IME (keyboard layout))

Expected behaviour: The window doesn't freeze, and I can type as usual.

Current behavoiur:

1. The window hang as soon as the key is pressed. The cursor will remain the "I" style, and even close button will not turn red when hover.
2. The whole window will not receive any keyboard and mouse window messages, until you do step 9.

It is 100% reproducable with latest VSCode or any Chromium based things.

PS: If not reproduced, try type through RDP first and then login physically and type. The DPI must changed, not sure if you can skip RDP and directly change DPI. The window must be minimized. I'll try post a video when possible. But yeah, you can try reproduce, its 100%.

Oh, about OS detail, as the associated issue said, it starts at Chromium 76, and I can remember suffering from this across Win10 and Win11, so, any Windows will suffer this technically.

The hang is technically not related to Chrome. Issue is in msctfuimanager. The workaround crrev.com/c/5365680 makes it even worse as now all the TSF objects in |TSFBridgeImpl::Initialize| have to be CoCreate'd that causes performance issues as well. Reverting this hacky fix so we can work on a more resilient and proper fix. Also cc'ing yukawa@

We're also getting reports in Edge that after this fix, the browser hangs for random reasons during typing. We saw the callstacks and msctfuimanager is waiting on DirectAccess for a response while the InputMethodWinBase calls PeekMessage.

Hang stack: Call Site

00 win32u!ZwUserPeekMessage
01 user32!_PeekMessage
02 user32!PeekMessageW
03 ui::InputMethodWinBase::HandlePeekMessage
04 ui::InputMethodWinBase::DispatchKeyEvent
05 aura::WindowEventDispatcher::PreDispatchKeyEvent
06 aura::WindowEventDispatcher::PreDispatchEvent
07 ui::EventDispatcherDelegate::DispatchEvent
08 ui::EventProcessor::OnEventFromSource
09 ui::EventSource::DeliverEventToSink
0a ui::EventSource::SendEventToSinkFromRewriter
0b views::DesktopWindowTreeHostWin::HandleKeyEvent
0c views::HWNDMessageHandler::OnKeyEvent
0d msedge!views::HWNDMessageHandler::_ProcessWindowMessage
0e views::HWNDMessageHandler::OnWndProc
0f gfx::WindowImpl::WndProc

cc'ing siliu@ as well

FWIW, I'm not able to repro the initial issue with dpi change and Pinyin IME. Assigning this to Siye for initial investigation.

Your callstack is exactly where I observed when it hangs on my side. It actually not hanged and just no mouse and keyboard events which makes the window looks hanged.

I'm surpurised that you cannot reproduce the problem. Try find a VSCode that use Chromium < 123. How about try this way:

1. Adjust your DPI to 150% or something
2. Open that VSCode and type with Pinyin in Chinese mode. "中" should be displayed in the tray indicating the mode.
3. YOU MUST MINIMIZE THE WINDOW
4. Login via RDP, ENSURE THE DPI IS DIFFERENT
5. Reopen the window, type and hang.
6. If not hang, just minimize and relogin physically and do step 5 again.

Minimize and DpiChange is essential. You can also try set system language to Chinese but I think it is not relevant.

At last, could you provide more information about the error on msctfuimanager and how can we fix it? Any future plans and ETA about that fix? Could it be workarounded on Chromium, or it needs user to apply a KB update on Windows?

It has confused me for 5 years since Chormium use TSF as default. If it cannot be investigated shortly, I might need to see if there's a better way to workaround.

FYI, I can reproduce this 100% on any Windows 10 and Windows 11 machine (under Chinese system language, but I think it is irrelevant). So please do try reproduce it again. I'm also unable to provide any dumps, as I already tried pause the process when it hangs, and no thread stucks at suspicious place. The UI thread is just at PeekMessage and I also printed out all events it can process. The function is just no longer pump Keyboard and Mouse events after key press, so it must be eaten by some Windows internal probably CTF, it do pumps some other messages if you can debug it with some windows message hooking tools, Spy++, etc..

I can even provide a recording about the whole reproducing, if need one.

Could you please send us a heap dump as well? If you can repro it in Edge, go to task manager and right click on the Browser process and then select "Create memory dump file" See the attached image.

Minimizing or focusing on other window may break the hang state, unless you focus it back and type it will hang again. So I'm unsure if the dump is useful.

The best way to see the stacks is: build chromium manually, and run content_shell. Then, add a global variable in ime/win/text_store.cc, and when OnKeyTraceDown is called, set a flag, when OnKeyTraceUp is called, unset the flag. Then start a new thread to detect that flag is not unset for seconds, then trigger the debugger to break. This will be the best option.

PS: I'm not the only one who suffer this, there're many hang report in electron and vscode repo, links should be in previous issue.

are you saying that the hang goes away if you click outside the Chrome window and click back on it again?

The hang will goes away if you press Windows key, click outside window, or alt+tab to switch window. It will not hang directly when you click it back, it will hang again when you press key (however, not 100% depends on the way you switch focus). But I'm pretty sure it will 100% hang for the first time if you follow the reproduce step. Are you sure the monitor scaling is different when physically login and login with RDP?

FYI, sometimes when the hang goes away, all keyboard and mouse events may like a floor being released (a queue finally gots read) and making the window do all the key stroke and mouse click or drag during the hang.

I think I have a repro:

1. Make sure that the physical machine DPI and remote desktop DPI is different. (My physical machine DPI is 100%, my remote desktop DPI is 150%).
2. Remote into my physical machine. Switch to Chinese input mode. Type any chinese character such as "中" (zhong).
3. Minimize browser window.
4. disconnect remote session and login on physical machine.
5. reopen browser window. start typing.
6. Observe hang.

After hang, I can recover by switching focus to other application and switching focus back to browser.

Like a flood, I mean. All stucked events comes back.

The DPI I mean is the scaling ratio in the Display Setting of your monitor, just to make sure you don't misunderstood it.

Any good news about repo? BTW, is it possible to chat on some IM to accelerate the communication about debugging?

Hi guys, hope you could take a look this week :)

I am able to repro the issue. See https://issues.chromium.org/issues/328859185#comment21. This is not a very high priority issue since there is a work around. I'll start investigation soon. Thanks

The workaround has beed reverted by sn...@, so unless we put the workaround back, the issue will still exists in Chromium.

I tried to find a new workaround without resetting TSF, but I can't find one now, it seems more complicated if we only re activate thread manager. Maybe you can suggest a new one?

We discussed this with our TSF partners, and they asked us to get a memory dump of the ctfmon process. carolwolfking@ is it possible to get the dump of the ctfmon process during the hang?

Also, they mentioned that reinitializing TSF during DPI change is unnecessary and nothing special is required to do in TSF when WM_DPICHANGED message is received. There was a fix in Windows related to a similar issue in the past, but not sure if that patch is working correctly, so we need to do more investigation before we add any workarounds.

If the fix was pushed through Windows Update I should already applied, but not useful.

I think it is possible. I could write a program that dumps the processes every 5 seconds and just reproduce, it can prevent focusing to other window which may break the hang state.

If you can reproduce, maybe you can also do that.

Here's a dump with all related processes I think: "ChsIME.exe", "ctfmon.exe", "content_shell.exe", "TextInputHost.exe", "explorer.exe", "TabTip.exe"

They are dumped when the content_shell goes into the hang state with the reproduce step with following params:

auto dumpType = MiniDumpNormal | MiniDumpWithHandleData | MiniDumpWithUnloadedModules | 
    MiniDumpWithProcessThreadData | MiniDumpWithFullMemoryInfo | MiniDumpWithThreadInfo |
    MiniDumpWithFullAuxiliaryState | MiniDumpWithTokenInformation | MiniDumpWithModuleHeaders;
BOOL success = MiniDumpWriteDump(hProcess, processID, hFile, (MINIDUMP_TYPE)dumpType, NULL, NULL, NULL);

The content_shell didn't unfocus when the dump happens, so it is exactly same hang state, the dumps should be valid.

Some fun facts, probably could help you as clue:

1. As #21 describes, first use an RDP session, then use physical login seems an mandatroy step order to reproduce.

2. The following code (resetting document map) if runned when OnDpiChanged, will also prevent window from hang, but will reset Chinese mode into english mode (not English keyboard layout, just english mode. Actually same behaviour restarting whole TSFBridge)

void TSFBridgeImpl::Reactivate() {
  DCHECK(base::CurrentUIThread::IsSet());
  
  for (auto& pair : tsf_document_map_) {
    TSFDocument& document = pair.second;
    Microsoft::WRL::ComPtr<ITfContext> context;
    Microsoft::WRL::ComPtr<ITfSource> source;
    if (document.source_cookie != TF_INVALID_COOKIE &&
        SUCCEEDED(document.document_manager->GetBase(&context)) &&
        SUCCEEDED(context.As(&source))) {
      source->UnadviseSink(document.source_cookie);
        }
    if (thread_manager_ != nullptr) {
      Microsoft::WRL::ComPtr<ITfSource> key_trace_sink_source;
      if (document.key_trace_sink_cookie != TF_INVALID_COOKIE &&
          SUCCEEDED(thread_manager_.As(&key_trace_sink_source))) {
        key_trace_sink_source->UnadviseSink(document.key_trace_sink_cookie);
          }
      Microsoft::WRL::ComPtr<ITfSource> language_profile_source;
      if (document.language_profile_cookie != TF_INVALID_COOKIE &&
          SUCCEEDED(input_processor_profiles_.As(&language_profile_source))) {
        language_profile_source->UnadviseSink(document.language_profile_cookie);
          }
    }
  }
  tsf_document_map_.clear();
  InitializeDocumentMapInternal();
}

I did some dig, by directly AdviseSink again, but it won't work:

  for (auto& pair : tsf_document_map_) {
    TSFDocument& document = pair.second;
    Microsoft::WRL::ComPtr<ITfContext> context;
    Microsoft::WRL::ComPtr<ITfSource> source;
    if (document.source_cookie != TF_INVALID_COOKIE &&
        SUCCEEDED(document.document_manager->GetBase(&context)) &&
        SUCCEEDED(context.As(&source))) {
      source->UnadviseSink(document.source_cookie);
      source->AdviseSink(IID_ITfTextEditSink,
                        static_cast<ITfTextEditSink*>(document.text_store.get()),
                        &document.source_cookie);
    }
    if (thread_manager_ != nullptr) {
      Microsoft::WRL::ComPtr<ITfSource> key_trace_sink_source;
      if (document.key_trace_sink_cookie != TF_INVALID_COOKIE &&
          SUCCEEDED(thread_manager_.As(&key_trace_sink_source))) {
        key_trace_sink_source->UnadviseSink(document.key_trace_sink_cookie);
        key_trace_sink_source->AdviseSink(IID_ITfTextEditSink,
                          static_cast<ITfTextEditSink*>(document.text_store.get()),
                          &document.key_trace_sink_cookie);
          }
      Microsoft::WRL::ComPtr<ITfSource> language_profile_source;
      if (document.language_profile_cookie != TF_INVALID_COOKIE &&
          SUCCEEDED(input_processor_profiles_.As(&language_profile_source))) {
        language_profile_source->UnadviseSink(document.language_profile_cookie);
        language_profile_source->AdviseSink(IID_ITfLanguageProfileNotifySink,
                                   static_cast<ITfTextEditSink*>(document.text_store.get()),
                                   &document.language_profile_cookie);
          }
    }
  }

So it must be something to do with recreating a TextStore

Thank you for sharing these memory dumps! I have sent this to our TSF team internally to investigate further. Will let you know if there is any update.

Thanks a lot. I just figured out that only resetting TSFTextStore could also solve the problem, I'm still trying to nail down which minimum component specifically need to reinitialize to solve the issue. I'll compare with firefox's design, thanks for providing that.

Any updates from TSF team? I'm going to write some 😈 workaround if not.

So, any updates here? I have no time to compare the difference with firefox. A fix from internal team would be nice.

Sorry for the delayed response. We asked Windows Input team and got response back. The root cause is in Windows TSF code. After entering this broken state, TSF drops any future IME inputs. The fix is made and should be released to public July - August.

Great, how do we access the update? From Windows Updates or need a canary build of Windows Insider?

Yes, it will go through Windows Update. I'll update the thread once I have a build number available. Thanks.

Any good news?

Any updates? It's almost Sept.

Hi, It's been Sept, any updates or delay plan for this bug?

Hi, any news? 🥹 Will it be available when 24H2 officially ships?

Hi, sorry for the delayed response. just got a response from Windows team. Unfortunately, the original fix was scheduled to release in September. However, there was a regression, so the fix was reverted. The new fix is under test and won't be released until several months. I'll update the thread once I heard back from Windows team again.

Any updates?

By the way, since we already know it was introduced when tsf becomes default using electron, is it possible to enable tsf before tsf becomes default, and find out which commit caused this?

Can you at least share what API caused this problem? Maybe Chromium could avoid using that buggy function, because FireFox doesn't have this issue

This issue is not caused by one API. In general, TSF forcibly terminate ctfmon when the session was disconnected which causes TSF no longer accept IME inputs. The issue is fixed now and is in pipeline to release. I can share first available OS build number once available.