[Problem/Bug]: Transparent (alpha=0) full-screen WebView2 window still hit-tests and swallows all mouse input intended for windows beneath it

[mrayhankhan]

What happened?

Reporting as an end user rather than the app developer — I traced a complete Windows desktop input failure to a WebView2 window, and it may indicate a robustness gap on the WebView2 side.

WhatsApp Desktop (Microsoft Store, 2.2630.101.0) hosts its UI in WebView2. When the app is not on the active Windows virtual desktop, its WebView2 window is left visible and full-screen with layered alpha = 0 rather than being hidden.

Because WS_EX_TRANSPARENT is not set, that fully transparent window keeps hit-testing, so it absorbs every mouse click intended for the Windows desktop underneath it. The desktop on that virtual desktop becomes completely unresponsive: no icon selection, no double-click to launch, no right-click context menu.

Measured via EnumWindows + GetWindowLong + GetLayeredWindowAttributes:

hwnd    = 67678
process = msedgewebview2.exe (child of WhatsApp.Root.exe)
class   = Chrome_WidgetWin_1
title   = "(118) WhatsApp"
rect    = (0,3)-(1920,1080)      -> full screen
exStyle = 0x8280080
alpha   = 0                       (GetLayeredWindowAttributes, flags = LWA_ALPHA)
IsWindowVisible = TRUE

exStyle = 0x8280080 decodes to:

• WS_EX_LAYERED (0x00080000) — with alpha 0, renders 100% transparent
• WS_EX_NOACTIVATE (0x08000000) — clicking it changes no focus, so the user gets zero feedback
• WS_EX_TOOLWINDOW (0x00000080) — absent from Alt+Tab, so the window cannot be found or closed
• WS_EX_NOREDIRECTIONBITMAP (0x00200000)

WS_EX_TRANSPARENT (0x00000020) is not set.

Click-level logging confirms where input lands. On the affected virtual desktop, WindowFromPoint on each mouse-down resolves to the WebView2 window while the foreground window remains Progman:

LEFT  at (480,322) under=[Chrome_RenderWidgetHostHWND<-Chrome_WidgetWin_1] proc=msedgewebview2 | FG=[Progman]

On an unaffected virtual desktop, the same click resolves correctly to the desktop:

LEFT  at (537,120) under=[SysListView32<-SHELLDLL_DefView<-Progman] proc=explorer title='FolderView'

Repro steps

1. Create several Windows virtual desktops (mine: 4).
2. Open WhatsApp Desktop on desktop 4.
3. Work on desktop 3 for a while.
4. Return to desktop 4, minimize all windows, and try to click desktop icons or right-click the wallpaper.

100% reproducible, and it survives a full restart of WhatsApp. Quitting WhatsApp restores desktop input immediately.

Expected behavior / question

Should the WebView2 host window continue to hit-test while layered at alpha 0? If a host app fades the surface instead of hiding it, WebView2 could defensively set WS_EX_TRANSPARENT (or unmap the window) so it cannot silently capture input destined for windows beneath it.

The NOACTIVATE + TOOLWINDOW + alpha=0 combination is what makes this pathological: the window is invisible, unlistable, unfocusable, and click-absorbing simultaneously — effectively undiagnosable for an end user.

If this is purely host-app misuse I'm happy to redirect it to WhatsApp, but the impact — an OS-level desktop rendered unusable with no visible cause — seemed worth surfacing here.

Environment: Windows 11 build 10.0.26200 · WebView2 Runtime 151.0.4129.59 · single 1920x1080 display

Importance

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

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

151.0.4129.59

SDK Version

N/A — reporting as an end user, not building the app

Framework

Win32

Operating System

Windows 11

OS Version

build 10.0.26200

Repro steps

Repro steps

1. Create several Windows virtual desktops (mine: 4).
2. Open WhatsApp Desktop on desktop 4.
3. Work on desktop 3 for a while.
4. Return to desktop 4, minimize all windows, and try to click desktop icons or right-click the wallpaper.

100% reproducible, and it survives a full restart of WhatsApp. Quitting WhatsApp restores desktop input immediately.

Expected behavior / question

Should the WebView2 host window continue to hit-test while layered at alpha 0? If a host app fades the surface instead of hiding it, WebView2 could defensively set WS_EX_TRANSPARENT (or unmap the window) so it cannot silently capture input destined for windows beneath it.

The NOACTIVATE + TOOLWINDOW + alpha=0 combination is what makes this pathological: the window is invisible, unlistable, unfocusable, and click-absorbing simultaneously — effectively undiagnosable for an end user.

If this is purely host-app misuse I'm happy to redirect it to WhatsApp, but the impact — an OS-level desktop rendered unusable with no visible cause — seemed worth surfacing here.

Environment: Windows 11 build 10.0.26200 · WebView2 Runtime 151.0.4129.59 · single 1920x1080 display

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response