Fix-restore-focus-on-desktop-switch

[DinMon]

Summary

When switching between virtual desktops, the previously focused window on the target desktop now automatically regains focus. This fixes the issue where users had to manually click on a window to focus it after switching desktops.

Problem

When switching virtual desktops using keyboard shortcuts, Windows does not automatically restore focus to the previously focused window on the target desktop. Users had to manually click on a window to give it focus.

Solution

Added focus restoration logic to the OnCurrentDesktopChanged event handler in TilingService.Private.cs:

• Uses async dispatcher with 100ms delay to ensure Windows completes the desktop transition before attempting to set focus
• Retrieves the tracked focused window for the desktop using GetFocus()
• Falls back to finding any visible window on the desktop if no tracked focus exists
• Uses FocusHelper.ForceActivate() to restore focus
• Handles edge cases gracefully (closed windows, minimized windows, exceptions)

[veselink1]

Hi, thanks for your PR. I really appreciate it.

When switching virtual desktops using keyboard shortcuts, Windows does not automatically restore focus to the previously focused window on the target desktop. Users had to manually click on a window to give it focus.

I've not found this to be the case, and I cannot reproduce this. I'd really like to understand better why that is the case first.

I'd be curious to learn what Windows OS version and FancyWM version you've tested this on, and what hotkeys you are using (the built-in Windows ones or specific FancyWM command?). Thanks.

[DinMon]

I’m running Windows 11 Enterprise, version 25H2 (Windows 11 2025 Update), with FancyWM 2.18.2.3, and my activation hotkey is set to Ctrl + Shift (pressed and released together before the keybinding).

[DinMon]

Also if you are able to check #436 which fixes autofocus for added window from some third-party launcher(PowerToys), not sure if everyone will face such issue or it is specific to me

[veselink1]

Thanks for the additional details. I think I've managed to reproduce this at least partially.

In my testing, when you move between desktops, if the window that was on the desktop before the switch not present on the new desktop, the window previously focused on the new desktop becomes focused.

So if I have two explorer windows, one on desktop 1 and one on desktop 2, and I focus explorer on desktop 2, then switch to desktop 1, the explorer window there is focused. Then when I switch back, the other explorer window is focused. This is all how I expect Windows to behave.

However, if I switch to desktop 1 and click the taskbar, then switch to desktop 2, the taskbar remains focused. This seems to be because the taskbar "window" is present on both desktops. I wonder if what you are seeing is a variation on this?

I'm trying to make sure we can isolate the exact case, before we decide how to address it. I'm a bit hesitant to merge the fix you have, since it forces input focus to move to the window returned by m_backend.GetFocus. This is the focused tiling window, not necessarily the window which receives input.

Specifically, it breaks if you have a floating window, since those are not managed by m_backend. I prefer to avoid making input focus changes, unless explicitly triggered by action.