fix(fancyzones): Prevent stuck drag state and key swallowing (#410)

[crutkas]

Summary

Fix FancyZones stuck drag state that permanently steals keyboard input (Shift+key combos and number keys).

Root Cause

When a window is destroyed mid-drag (Alt+F4, task kill, app crash), EVENT_SYSTEM_MOVESIZEEND never fires. The drag state machine stays in m_dragging = true permanently, causing:

• All Shift+key combos swallowed — the LL hook returns 1 for any keystroke when Shift is held during IsDragging()
• Number keys eaten — quickLayoutSwitch fires on bare digit presses during (stuck) drag with no modifier requirement
• Extra LL hooks stay installed — GenericKeyHook and MouseButtonsHook remain active system-wide

Changes

A1: Subscribe to EVENT_OBJECT_DESTROY and clean up drag state

• Add EVENT_OBJECT_DESTROY to the WinEvent subscription array
• Route to WM_PRIV_WINDOWDESTROYED message handler
• If destroyed window matches the dragged window (via GetDraggedWindow()), force MoveSizeEnd()
• Make MoveSizeEnd() always disable dragging state even if m_windowMouseSnapper is null

A2: Narrow Shift+key swallowing to bare VK_SHIFT only

• Change IsDragging() && shift to only suppress VK_LSHIFT / VK_RSHIFT themselves
• Other Shift+key combos (Shift+A, Shift+1, etc.) now pass through during drag

A3: Require Win+Ctrl+Alt for quickLayoutSwitch during drag

• Prevents bare number keys from triggering layout switches during stuck drag

A4: Tag SwallowKey SendInput with dwExtraInfo

How to Reproduce (before fix)

1. Enable FancyZones with Shift-drag mode (default)
2. Start dragging a Notepad window while holding Shift (zone overlay appears)
3. Kill the Notepad process from Task Manager while still dragging
4. Open a new Notepad and try typing Hello 123
5. Bug: Number keys and Shift+key combos are eaten. Zone overlay stuck on screen.

How to Verify (after fix)

1. Same steps — after kill, zone overlay disappears, typing works normally
2. Normal Shift+drag still works end-to-end

Related Issues

• Fixes PowerToys steals my number keys! microsoft/PowerToys#410 (58 upvotes) — "PowerToys steals my number keys!"
• Fixes FancyZones stuck active if window closes while dragging microsoft/PowerToys#43996 — "FancyZones stuck active if window closes while dragging"

PR Checklist

• Builds clean on x64 Release
• Manual verification per repro steps above

[yeelam-gordon]

The EVENT_OBJECT_DESTROY path is the right primary fix for microsoft#410 cleanly handles Alt+F4 / app-crash mid-drag. Solid.

One coverage question: are there code paths where the dragged window survives but the user-physical-drag context is lost? A few that I think still leave m_dragging = true:

• WTS_SESSION_LOCK / WM_WTSSESSION_CHANGE (user hits Win+L mid-drag)
• Display configuration change (DPI / resolution / monitor add-remove while dragging across the seam)
• Foreground steal via Win+Tab / UAC consent / focus-thief

If the destroy event doesn't fire in those, the LL hook will keep swallowing Shift-combos until the next drag completes. Probably out of scope here, but worth a follow-up issue.

[crutkas]

Rebased onto main and dropped the unrelated commits that had crept in, so this PR is now scoped to just the stuck-drag / key-swallowing fix.

Agreed that EVENT_OBJECT_DESTROY is the right hook for the core issue. The remaining gaps you called out — session lock (WTS_SESSION_LOCK), display/topology change, and a foreground steal mid-drag — are real but out of scope here; I'll track them in a follow-up issue rather than widen this PR.

(Also swapped the placeholder window-message identifier for a real GUID to match the rest of FancyZonesWinHookEventIDs.cpp.)

[crutkas]

Superseded by the upstream PR against microsoft/PowerToys: microsoft#48569 (rebased onto current main, builds/tests verified). Closing this intra-fork review PR.