[Bug]: Visual-DComp WebView stops responding while SendMouseInput continues to succeed

Description

A WebView2 hosted with Visual-DComp eventually stops responding to mouse input after repeatedly pressing the left mouse button inside the WebView, dragging outside the host window, and releasing it.

The host application continues to receive mouse messages and forwards them through ICoreWebView2CompositionController::SendMouseInput. The calls return S_OK, but the WebView content no longer responds to mouse interaction.

This does not appear to be related to app-region: drag.

Environment

• Runtime: 152.0.4191.66
• Framework: Win32 C++
• Hosting mode: Visual-DComp
• API: ICoreWebView2CompositionController::SendMouseInput
• Sample: WebView2APISample

Reproduction steps

1. Run WebView2APISample in Visual-DComp mode.
2. Load a minimal HTML page without app-region: drag or -webkit-app-region: drag.
3. Press and hold the left mouse button inside the WebView.
4. Drag the mouse outside the host window or toward the screen edge.
5. Release the mouse button.
6. Repeat this operation several times.
7. Move the mouse and click inside the WebView after it becomes unresponsive.

Expected behavior

The WebView should continue to respond to mouse clicks, dragging, scrolling, and keyboard input.

Actual behavior

The WebView content becomes unresponsive. The host window remains responsive and continues to receive and forward mouse input.

Diagnostics

During the unresponsive state:

• WM_MOUSEMOVE continues to arrive at the host.
• WM_LBUTTONDOWN and WM_LBUTTONUP are received in pairs.
• SendMouseInput continues to return S_OK.
• WM_NCHITTEST returns HTCLIENT (1).
• GetNonClientRegionAtPoint returns COREWEBVIEW2_NON_CLIENT_REGION_KIND_CLIENT (1).
• No CAPTION region is reported.
• No WM_CAPTURECHANGED event transfers capture to CLIPBRDWNDCLASS.
• ProcessFailed is not raised with RenderProcessUnresponsive.

For example, after the WebView becomes unresponsive, the host still logs:

WM_LBUTTONDOWN
SetCapture ... hostCapture=1
SendMouseInput ... WM_LBUTTONDOWN ... hr=0x00000000

WM_LBUTTONUP
ReleaseCapture completed ... capturing=0
SendMouseInput ... WM_LBUTTONUP ... hr=0x00000000

Mouse movement after the failure also continues to produce:

SendMouseInput ... WM_MOUSEMOVE ... hr=0x00000000

The test page does not define app-region: drag or -webkit-app-region: drag, and the WebView reports CLIENT for the tested coordinates.

Questions

Is there a known issue in WebView2 Runtime 152 affecting mouse input processing in Visual-DComp hosting after dragging outside the host window?

Could the Composition input pipeline enter an internal state where SendMouseInput returns S_OK, but the renderer or WebView input state no longer processes the events?

Is there a native API or recommended recovery procedure for detecting and recovering from this state when ProcessFailed is not raised?

Run WebView2APISample in Visual-DComp mode with the minimal HTML page and reproduce the repeated drag-outside-and-release sequence. Start by tracing SendMouseInput, mouse capture, WM_NCHITTEST, GetNonClientRegionAtPoint, and ProcessFailed using the diagnostics in the issue. Done means identifying whether Runtime 152 has a known input-state failure and documenting a supported detection or recovery procedure.