DEV Community: Daming Wu

Why PID equality breaks WebView2 focus detection—and how to verify focus safely

Daming Wu — Wed, 26 Aug 2026 19:55:50 +0000

A desktop dictation tool has a deceptively dangerous job: it waits while speech recognition runs, then writes text into another application's focused control. If focus changes during that delay, the text may land in a chat, terminal, or password field the user never intended.

In VocalCode I capture a focus token when recording starts and validate it again immediately before insertion. On Windows that token includes the foreground HWND and the UI Automation runtime ID of the exact focused element.

The conservative check that was still wrong

My original code also required IUIAutomationElement::CurrentProcessId to equal the PID that owns GetForegroundWindow().

That works for ordinary Win32 controls. It fails in Chromium, Electron, and WebView2 applications because the top-level HWND belongs to the host process while the focused text control may be provided by a separate renderer process. The control is legitimate, but PID equality rejects it.

The mistake was treating process identity as proof of visual/window membership.

Use the native window tree as the membership authority

The replacement algorithm is:

Capture GetForegroundWindow() and reject a null HWND.
Ask UI Automation for the focused element and capture its non-empty runtime ID.
Walk upward with the raw-view tree walker until an element exposes CurrentNativeWindowHandle.
Resolve GetAncestor(native_hwnd, GA_ROOT).
Require that root HWND to equal the captured foreground HWND.
Re-read both the foreground window and the focused UIA element after the ancestor walk to close the race.
At delivery time, recapture the token and require the foreground HWND, renderer PID, and runtime ID to match the token captured at recording start.

In simplified Rust, the pure membership decision looks like this:

struct FocusCandidate<'a> {
    foreground_window: u64,
    foreground_process_id: u32,
    element_process_id: u32,
    native_window: u64,
    native_root_window: u64,
    runtime_id: &'a [i32],
}

fn is_safe(c: &FocusCandidate<'_>) -> bool {
    c.foreground_window != 0
        && c.foreground_process_id != 0
        && c.element_process_id != 0
        && c.native_window != 0
        && c.native_root_window == c.foreground_window
        && !c.runtime_id.is_empty()
}

Notice what is absent: element_process_id == foreground_process_id. The renderer PID remains part of the identity token, but it is not used as the membership authority.

Closing the race matters

Walking a remote UIA provider can take time. During that walk the user can switch windows or controls. After verifying ancestry, the implementation therefore checks GetForegroundWindow() again and uses IUIAutomation::CompareElements against a freshly fetched focused element. At insertion time the complete token is validated again.

A different field in the same WebView is not considered equivalent.

Tests that caught the boundary

The pure predicate and token comparison make the important cases straightforward to test:

a same-process Win32 input is accepted;
a cross-process WebView2 input whose native root is the foreground window is accepted;
an element rooted in another foreground window is rejected;
changing either the window or exact runtime ID while speech recognition runs is rejected.

The broader lesson is that modern desktop UI process boundaries do not necessarily match window boundaries. If the safety question is “does this control belong to the user's foreground window?”, verify that relationship in the window tree and preserve the exact control identity across the asynchronous operation.

I found this while building VocalCode, an on-device push-to-talk utility for AI coding workflows. Founder disclosure: it is my product. The 30-day no-card build is at https://vocalcode.app/ if you want to test the behavior in real Win32, Chrome/Electron, or WebView2 fields.

Windows silently stops delivering WH_KEYBOARD_LL hook events when a Chromium window has focus (and the diagnostic hook hides it)

Daming Wu — Fri, 21 Aug 2026 17:20:42 +0000

I ship a push-to-talk dictation app for Windows (VocalCode). Hold a key, talk, release, text appears at the cursor. The "hold a key" part is a low-level keyboard hook — SetWindowsHookExW(WH_KEYBOARD_LL, …) — the same primitive every global-hotkey app on Windows uses. This is the story of the week it stopped working, the part of the story that made it unfindable, and the fix. The logger I wrote to chase it is MIT on GitHub: wh-keyboard-ll-chromium.

The symptom

The hook worked everywhere — terminals, editors, Explorer, native apps — except when a Chromium-family window was in the foreground. My own WebView2 settings window, and separately Electron and CEF apps. With one of those focused, the hook callback simply stopped being invoked. No error. No unhook. GetLastError had nothing to say. The keystrokes were delivered to the focused app just fine; my hook never saw them.

Focus a native window: events flow. Focus the Chromium window: silence. Completely reproducible on my machine, and completely absent from the usual search results.

The observer effect (this is the part that cost the week)

I did what you do. I installed a second diagnostic hook to log what the first one was missing.

The moment the diagnostic hook was in, the system delivered events to both hooks. Remove it, and the original went deaf again under identical conditions. A watched hook never misbehaves.

This has a nasty consequence: a minimal repro does not reliably reproduce. The repro program perturbs the very hook chain it is trying to observe. Every reduced test case I built passed, and the production binary kept failing. If you have hit this and concluded you were imagining it — you probably weren't.

What I believe is going on (hypotheses, not verdicts)

The documented contract allows it. A low-level hook that exceeds the LowLevelHooksTimeout budget can be silently removed or skipped, and Windows 10/11 will silently stop calling hooks it considers slow. Chromium pumps input very differently from native apps (raw input, a hot message loop, high-frequency pointer events). It is plausible that this shifts timing enough to trip the threshold — for the whole chain, or just for your position in it.
Hook-chain position matters, and installing or removing any hook reorders the chain. That alone would explain the observer effect: the diagnostic hook changed the chain, which changed the timing, which changed the outcome.
I could not find an API that says "your hook was skipped or removed for being slow." If you know one, I would genuinely like to hear about it — it is half the reason the repo exists.

What actually fixed it

I stopped depending on the global hook while my own WebView2 window had focus. A keydown listener inside the page answers the push-to-talk chord itself; the global hook keeps serving every native window. Shipped, and the failure disappeared for every user.

If your hotkey must work over other people's Chromium windows (Chrome, VS Code, Slack…), the pragmatic rules are:

Keep the hook callback microscopic. Post to your own thread and return immediately. No logging, no allocation, no locks inside it.
Detect prolonged silence while keys are clearly being typed — compare against GetAsyncKeyState polling — and re-install the hook when it happens. Ugly. Effective.

The logger

src/main.rs installs a WH_KEYBOARD_LL hook and prints one line per event: timestamp, key, and the executable plus title of the foreground window. Run it, type into different apps, and watch whether the lines stop when a Chromium window is focused.

cargo run --release --bin khook-logger

How to read it:

Lines flow in every app, Chrome included: your machine and timing do not trip it. Mine usually didn't either, until the app also had audio callbacks and a webview running.
Lines stop in exactly one app family: you have reproduced my week.
Your other hotkey app goes deaf only while this logger is not running: that is the observer effect, and I would love an issue with your setup.

Environment where I hit it: Windows 11 (23H2 and 24H2), Rust hook thread with a dedicated message pump, WebView2 (Edge 126+) same-process window; also reproduced against CEF-based apps.

Issues and war stories welcome — especially if you can disprove the timeout hypothesis with something better.

Windows silently stops delivering WH_KEYBOARD_LL events when a Chromium window has focus

Daming Wu — Sun, 16 Aug 2026 21:11:42 +0000

My first native-language tester said 'not usable yet' - it was the best thing that happened all week

Daming Wu — Sun, 16 Aug 2026 20:57:44 +0000

CPU-only local speech-to-text for driving coding agents: Parakeet TDT + Paraformer over Whisper

Daming Wu — Sat, 15 Aug 2026 07:01:38 +0000

I dictate prompts to coding agents (Claude Code, Cursor) all day. Typing paragraph-long prompts was my bottleneck, and I wanted the speech side fully local - push-to-talk, CPU-only, nothing leaving the machine. The model choices surprised me, so here's the stack.

What I ended up with

Built in Rust on sherpa-onnx:

NVIDIA Parakeet TDT v3 for European languages: one model covers 25 languages with automatic detection, and TDT decoding is noticeably lighter on CPU than Whisper-class encoder-decoder models in my use. It also emits its own punctuation.
Paraformer (zh-en bilingual) for Mandarin: code-switching ("??? function ?? async") is where general multilingual models fall apart, and a dedicated bilingual model handles it far better. Punctuation comes from a separate local CT-Transformer pass.
Models download on demand (a few hundred MB each); everything runs offline afterwards.

Why not Whisper

Nothing wrong with Whisper - but for live push-to-talk on CPU, the latency/quality point of TDT worked better for me, and Paraformer beat everything I tried on bilingual Mandarin. I deliberately don't publish latency numbers (too hardware-dependent to be honest about), so treat this as one person's experience, not a benchmark.

The part nobody talks about: insertion

Text insertion is harder than recognition. Getting clean text into whatever field has focus - terminal, editor, browser - across Windows and macOS is its own rabbit hole. The worst one: Windows silently stops delivering low-level keyboard hooks (WH_KEYBOARD_LL) when a Chromium-based window is focused. It's on record against Tauri and CEF too, and nothing you write inside the hook can fix it - the procedure is never entered. The fix is architectural: the focused window answers its own keydown events, and the global hook only owns the unfocused case. That one cost me a week.

Acronym handling matters more than WER for this use case: "m c p" has to come out as MCP, and a user-editable replacement dictionary catches project jargon the model can't know.

Disclosure

This shipped as a small paid app - VocalCode, USD 4.99 one-time with a 30-day free trial, at vocalcode.app - so I'm affiliated. The model discussion is the point of this post, though: if you're running TDT-family models for live dictation, or you've gotten good zh-en code-switching out of anything else local, I'd genuinely like to compare notes in the comments.