Switching to Russian input freezes warp

[peicodes]

• Windows version freezes after pressing ctrl-1, ctrl-2 etc. #7073
• Punto Switcher freezes Warp #8675

---

Linear: CODE-1764

[oz-for-oss]

@peicodes

This issue appears to overlap with existing issues:

• Windows version freezes after pressing ctrl-1, ctrl-2 etc. #7073 — Windows version freezes after pressing ctrl-1, ctrl-2 etc.
• Punto Switcher freezes Warp #8675 — Punto Switcher freezes Warp

If this report is meaningfully different, please comment with the additional context or distinguishing behavior so a maintainer can review it. Otherwise, a maintainer may close it as a duplicate after review.

Maintainer details

I concluded that this appears to be a duplicate Windows terminal-input freeze report for switching to Russian/non-Latin input, matching two existing open issues..

Duplicate reasoning

• Windows version freezes after pressing ctrl-1, ctrl-2 etc. #7073: The linked issue describes Warp freezing on Windows after keyboard-layout shortcut input, matching the same Russian/input-switch freeze symptom.
• Punto Switcher freezes Warp #8675: The linked issue describes Warp freezing when a Windows input-switching utility changes input state, matching the same Russian/input-switching freeze cluster.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[chilango74]

I've identified the root cause and submitted a fix: warpdotdev/winit#15

Root cause: In winit's WM_KEYDOWN handler (keyboard.rs), next_kbd_msg() (PeekMessageW) is called before the LAYOUT_CACHE mutex is properly released. PeekMessageW can synchronously dispatch pending sent messages — notably WM_INPUTLANGCHANGE from PuntoSwitcher, Yandex Keyboard, Chinese/Korean IME switchers, or Windows Ctrl+1/2/3 layout shortcuts. When the dispatched message re-enters the WNDPROC and tries to acquire LAYOUT_CACHE, the non-reentrant std::sync::Mutex deadlocks on the same thread.

The WM_KEYUP handler already has the correct lock ordering with an explicit comment: "We MUST release the layout lock before calling next_kbd_msg, otherwise it may deadlock". The fix applies the same pattern to WM_KEYDOWN and adds an explicit WM_INPUTLANGCHANGE handler.

Tested on Windows 11 with PuntoSwitcher — the deadlock is gone and layout switching works correctly.

Also working on submitting the same fix to upstream rust-windowing/winit, since the bug exists there too.

[acarl005]

@chilango74 Excellent thank you! I'll have a look soon.