Skip to content

Conversation

@Radomir-Aksenenko
Copy link

@Radomir-Aksenenko Radomir-Aksenenko commented Jan 20, 2026

Hey! Taking another shot at this after your feedback on the previous PR.

You were right - blocking all Alt keypresses was a bad idea. So I rewrote it
completely. Now it only kicks in when you actually use a layout switch combo
(Alt+Shift or Ctrl+Shift), not when you're just trying to open the menu.

Basically I track when these combos are pressed (KeyDown) and only then block
the menu activation on KeyUp. Regular Alt still works fine for accessing menus.

I use Russian + English daily so this bug was driving me crazy, had to fix it
myself instead of waiting. Tested it pretty thoroughly - layout switching works,
menu shortcuts work, everything seems good.

Builder and others added 2 commits January 19, 2026 12:33
…ft+Alt)

Fix editor losing focus and cursor position when switching keyboard layout

## Problem

Non-English speaking users who work with multiple keyboard layouts (e.g.,
English + Russian, English + German, English + Chinese, etc.) experienced
a frustrating issue when switching between languages using the standard
Windows keyboard shortcut Shift+Alt (or alternative combinations).

Every time users switched their input language while typing in the editor,
the text cursor would jump away from the current line, losing its position.
This forced users to:

1. Stop their workflow
2. Manually click back into the editor
3. Navigate back to where they were typing
4. Continue working

For users who frequently switch between languages (which is very common
when writing code with comments in native language, or working with
multilingual content), this could happen dozens of times per session,
severely impacting productivity and causing significant frustration.

## Root Cause

When pressing Shift+Alt to switch keyboard layout in Windows, the OS
generates a KeyUp event for the Alt key after the layout switch completes.
In Avalonia (and WPF), a standalone Alt key press activates the application's
main menu bar, which steals keyboard focus from the TextEditor control.

## Solution

Added a KeyUp event handler with tunnel routing strategy in MainWindow
that intercepts the Alt key release event before it reaches the menu.
When the editor has focus, the event is marked as handled, preventing
menu activation and preserving cursor position.

This fix specifically targets the keyboard layout switching scenario while
maintaining normal Alt key functionality for menu access when the editor
is not focused.

Affects all Windows users with multiple keyboard layouts configured.
Hey! Taking another shot at this after your feedback on the previous PR.

You were right - blocking all Alt keypresses was a bad idea. So I rewrote it
completely. Now it only kicks in when you actually use a layout switch combo
(Alt+Shift or Ctrl+Shift), not when you're just trying to open the menu.

Basically I track when these combos are pressed (KeyDown) and only then block
the menu activation on KeyUp. Regular Alt still works fine for accessing menus.

I use Russian + English daily so this bug was driving me crazy, had to fix it
myself instead of waiting. Tested it pretty thoroughly - layout switching works,
menu shortcuts work, everything seems good.

Let me know if there's anything else to tweak!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant