slint icon indicating copy to clipboard operation
slint copied to clipboard

Microsoft Pinyin Input Method, the interface may freeze.

Open gqf2008 opened this issue 5 months ago • 4 comments

Bug Description

What is the bug? When switching the input method to Microsoft Pinyin (Chinese input) while using the application, the UI becomes completely unresponsive (freezes). The application does not recover until forcibly closed and restarted.

Expected Behavior vs. Actual Behavior

  • Expected: Smooth transition between input methods without UI lag or freezing.
  • Actual: The UI freezes immediately upon switching to Microsoft Pinyin, requiring a force quit.

Steps to Reproduce

  1. Open the application (provide version/environment if applicable).
  2. Ensure the default input method is set to English (e.g., US keyboard).
  3. Switch to Microsoft Pinyin (Windows IME shortcut: Win + Space).
  4. Result: UI freezes. No further interaction is possible.

Error Messages/Logs

  • No visible error logs in the console.
  • (Optional: Attach crash logs if available, or note if the issue persists in debug mode.)

Image

Reproducible Code (if applicable)


Environment Details

  • Slint Version: main
  • Platform/OS: windows 10
  • Programming Language: rust
  • Backend/Renderer: default

Product Impact

No response

gqf2008 avatar Jun 17 '25 03:06 gqf2008

I tried for a while on two different machines (one virtual, one physical) to reproduce this, but ALAS no luck. I suspect that the issue is that the font fallback handling we have in place for femtovg ends up hanging the process while it scans for fonts to provide the glyphs. But on the other hand, this doesn't quite match your video.

tronical avatar Jun 17 '25 08:06 tronical

@gqf2008 Coudl you confirm if the freeze is permanent or if it recovers at some point? Do you see if the process is busy with disk activity? Would it be possible for you to run this in Visual Studio debugger?

tronical avatar Jun 17 '25 09:06 tronical

@tronical Apologies for the delayed response. Here are the technical details regarding the issue:

The freeze appears to be permanent when no user action is taken - both animations and IME become completely unresponsive, though disk and CPU activities remain normal.

In versions prior to 0.8, we needed to terminate the process and restart to recover. However, since version 0.8+, simply clicking any menu item on the left panel restores both animation and IME functionality.

Reproduction notes:

Consistently reproducible across two separate Windows 10 machines Behavior appears identical in both test environments Next steps: I'll allocate time this week to debug this in Visual Studio to better understand the root cause.

Let me know if you'd like me to investigate any specific aspects during the debugging session.

gqf2008 avatar Jun 17 '25 16:06 gqf2008

Thanks for the clarification. This is indeed quite different to what I thought. Unfortunately I have an even harder time explaining this bug :).

I wonder what could be causing this?

I'm attaching a clip of my Windows 11, showing the behaviour that I see.

https://github.com/user-attachments/assets/2d70cccb-666f-4ec1-8882-6bb783443ca0

Would you have any idea what I could change in my system / setup to reproduce the bug you're seeing?

tronical avatar Jun 18 '25 11:06 tronical

I closed this as a duplicate of another issue that I think is tracking exactly the same. However, the issue remains real - especially as several users have reported this now. I'm struggling to find a way to reproduce it and I'd be most grateful for any instructions how to do so. My Windows 11 installation is a European one, but I've installed the Chinese language packs and pinyin input method.

tronical avatar Jul 28 '25 13:07 tronical