[Problem/Bug]: AllowHostInputProcessing breaks pointer-captured custom window resizing and can lose mouse release

What happened?

Enabling CoreWebView2ControllerOptions.AllowHostInputProcessing on a windowed WebView2 controller breaks the pointer-capture lifecycle used by a custom frameless-window resize gesture.

The host is a Tauri/Wry application with undecorated windows. Each resize edge is an HTML hit zone. On primary pointerdown, the page calls setPointerCapture; subsequent pointermove events calculate a complete window rectangle, which the native host applies with SetWindowPos; pointerup applies the final rectangle and releases capture.

With AllowHostInputProcessing left at its default false, the resize cursor remains visible while the button is held, release ends the gesture, and resizing does not remain active.

With AllowHostInputProcessing = true:

• The resize cursor immediately reverts to the ordinary cursor after the press.
• Some releases are not delivered through the expected pointer/mouse path.
• The resize can remain latched after the physical button has been released. Moving near the edge may continue resizing until another click.

This was a controlled A/B test: the application code and binary configuration were otherwise identical, and toggling only AllowHostInputProcessing changed the behavior. Native message tracing also showed inconsistent or missing WM_LBUTTONUP delivery during affected gestures.

Adding document/window-level pointer and mouse release fallbacks, forcing the CSS cursor during capture, and checking the physical button state did not restore correct behavior. Disabling AllowHostInputProcessing immediately did.

This appears related to the broader input-state problems reported in #5613 and #5375, but it is a distinct custom-resize/pointer-capture reproduction and does not depend on AllowExternalDrop.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

152.0.4191.66

SDK Version

1.0.3650.58, through webview2-com / webview2-com-sys 0.38.2

Framework

Other: Tauri 2.10.3 and Wry 0.54.3, using a windowed Win32 WebView2 controller

Operating System

Windows 11

OS Version

10.0.26200, x64

Repro steps

1. Create a windowed WebView2 controller with AllowHostInputProcessing = true.
2. In the page, add an edge element with a resize cursor and touch-action: none.
3. On primary pointerdown, call setPointerCapture(event.pointerId).
4. While receiving pointermove, resize the native top-level window with SetWindowPos.
5. Release the primary mouse button away from the original edge.
6. Observe that the cursor reverts during the gesture and that release can be missed, leaving the custom resize active.
7. Repeat with AllowHostInputProcessing = false; the same resize implementation behaves normally.

Expected: Routing input through the host should preserve pointer capture, cursor feedback, and button-release semantics when the host does not consume the events.

Actual: Enabling host input processing changes those semantics and can leave the WebView in a stale resize/capture state.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version. This controller option and native-host resize path are not exposed by the ordinary browser.

Regression

Don't know. The A/B comparison is between the option enabled and disabled on the same Runtime, rather than between Runtime versions.

Last working version (if regression)

Not established.

No repository files or tests are identified. Start with the seven-step A/B reproduction using AllowHostInputProcessing and compare native WM_LBUTTONUP delivery with the option enabled and disabled; done means pointer capture, cursor feedback, and button-release semantics remain correct without leaving the resize gesture latched.