Host app's global WH_KEYBOARD_LL hook receives no key events while a wry WebView2 window has focus (Windows)

[nayballs]

Describe the bug

On Windows, a host application's global WH_KEYBOARD_LL hook (used for a global push-to-talk/dictation hotkey) receives no keyboard events at all while one of the app's own wry/WebView2 windows has focus. The same hook receives every keystroke normally when any other application's window is focused.

Evidence from a real app (logging at the hook callback):

• Hotkey pressed with Notepad/terminal/any foreign window focused → hook callback fires, key handled. Reliable across hours of testing.
• Hotkey pressed with one of our own WebView2 windows focused → zero hook callbacks — the callback is never invoked (not a matching/logic issue; entry-level logging shows nothing). The un-suppressed key is then delivered to the focused webview as a normal DOM keydown (it types into inputs).
• Synthetic input (SendKeys/keybd_event) reproduces it identically: silent when our webview is focused, works otherwise.
• The hook is installed on a dedicated thread with a message pump; the callback does only atomics + a channel send (no blocking work), and we re-install the hook every 30 s as self-healing — neither helps while the webview is focused.

Our working hypothesis is that WebView2/Chromium installs its own low-level keyboard hook (or equivalent raw-input interception) when its window gains focus, landing ahead of the host's hook in the LL hook chain and not chaining onward — but we haven't proven the mechanism, only the observable behavior.

Why report it here

Any wry-based app that also uses a global WH_KEYBOARD_LL hotkey hook (dictation tools, push-to-talk, screen recorders) will silently lose its hotkey exactly when its own UI is focused — which is bafflingly hard to diagnose because a non-firing hook leaves no trace. If this is known/expected WebView2 behavior, a note in wry's Windows docs would save others a lot of pain; if not, it may warrant a WebView2Feedback escalation.

Workaround that works well: have the app's own pages listen for the hotkey as a DOM keydown (capture phase) and invoke the same action — since the un-hooked key reaches the focused document normally.

Reproduction

Host app: Tauri 2.11.3 / tauri-runtime-wry 2.11.4, Windows 11 (10.0.26200), Edge WebView2 runtime. Install a WH_KEYBOARD_LL hook from a dedicated thread; log at callback entry; focus the wry window; press the hooked key. We can extract a minimal repro from https://github.com/nayballs/Yap (see src-tauri/src/input_hook.rs) if useful.

Expected behavior

The host process's low-level keyboard hook receives key events regardless of which window has focus — or the interaction is documented.

Platform and versions

wry (via tauri-runtime-wry 2.11.4), tauri 2.11.3
Windows 11 10.0.26200, WebView2 (current evergreen)