Description
What happened?
Summary
We recently spent some time debugging a severe regression in our application after the Evergreen WebView2 Runtime updated to version 152.0.4191.x. We are sharing our findings here to help other developers who might run into the same issue.
If your application uses borderless windows with custom drag regions (app-region: drag / -webkit-app-region: drag), you may find that tooltips, dropdowns, or overlay buttons suddenly act as drag handles and swallow mouse clicks.
Root Cause
WebView2 v152 pulled in upstream Chromium commit 9100cdc8 (implementing CSSWG issue 13101), which enforces explicit CSS inheritance for the window-drag / app-region properties.
Previously, if you had a parent container with app-region: drag, an overflowed child element (like a floating tooltip) did not inherit the drag behavior. In v152+, overflowed children now automatically inherit app-region: drag. If you rely on native Win32 hit-testing (e.g., GetNonClientRegionAtPoint), the OS will treat these elements as HTCAPTION, turning standard clicks into window drag events.
The Workaround / Fix
To fix this, you must explicitly declare app-region: no-drag; (and -webkit-app-region: no-drag;) on any interactive overlays, tooltips, or modals that sit on top of a draggable surface.
Recommendation for the WebView2 Team
Since this is an intentional standards-alignment change from Chromium, we are not expecting a code fix. However, because this is a silent breaking change for desktop applications utilizing GetNonClientRegionAtPoint, we recommend adding a note about this behavioral shift to the WebView2 release notes or documentation for v152 to save other developers from having to bisect this regression.
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
152.0.4191.53
SDK Version
No response
Framework
Win32
Operating System
Windows 11
OS Version
No response
Repro steps
- Create a borderless/frameless WebView2 window that relies on
GetNonClientRegionAtPoint(orIsNonClientRegionSupportEnabled) to handle window dragging. - Load an HTML document containing a parent element configured as a drag region, and a child interactive element (like a button) that overflows or sits within it, without explicitly disabling the drag region.
Minimal HTML/CSS Example:
<style>
.main-container {
-webkit-app-region: drag; /* Parent is draggable */
height: 100vh;
background: #f0f0f0;
}
.tooltip-button {
/* Missing -webkit-app-region: no-drag; */
position: absolute;
top: -20px; /* Overflowing the standard flow */
cursor: pointer;
}
</style>
<div class="main-container">
<button class="tooltip-button" onclick="alert('Clicked!')">
Click Me
</button>
</div>- Attempt to left-click the "Click Me" button.
Expected Behavior:
The button registers the click event (triggering the alert) and behaves as a standard interactive web element. (This was the behavior in WebView2 v151 and earlier, as the overflowed child did not inherit the drag property).
Actual Behavior:
The click event is swallowed by the OS. GetNonClientRegionAtPoint reports the button as a drag region (HTCAPTION), and holding the mouse down initiates a window drag/move action instead of clicking the button.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Regression in newer Runtime
Last working version (if regression)
Runtime 151.0.4129.50
Activity
xystar2012 commentedon Sep 9, 2026
Even on simple pages that don't have any app-region attribute, the mouse stops responding. This issue is very serious. Should we issue an emergency fix and revert this merge?
Steps to reproduce:
#5695
xystar2012 commentedon Sep 9, 2026
Omer Mor (@OmerMor) Chetan Pandey (@chetanpandey1266)
chetanpandey1266 commentedon Sep 11, 2026
xystar2012 the repro step you gave didn't worked for us. We are able to repro it with the app-region change and are able to mitigate it by the steps shared by Omer. Can you give us a minimal repro app for the scenario you are facing.
xystar2012 commentedon Sep 11, 2026
xystar2012 commentedon Sep 11, 2026
input this text to console:
<title>Test Page</title> 这是一段简单的测试文本。 `; Chetan Pandey (@chetanpandey1266)document.documentElement.innerHTML = `
xystar2012 commentedon Sep 11, 2026
zprettytext commentedon Sep 14, 2026
I was able to reproduce the same issue using the official WebView2APISample from Microsoft.
The issue is reproducible in Composition Mode. I did not make any changes to the WebView2 host implementation. I only replaced the page content with the following simple HTML:
Environment
4255.0153.0.4234.32C:\tools\WebView2Samples\SampleApps\WebView2APISample\Debug\x64C:\Program Files (x86)\Microsoft\EdgeWebView\Application\153.0.4234.32C:\tools\WebView2Samples\SampleApps\WebView2APISample\Debug\x64\WebView2APISample.exe.WebView2Non-sharedThis confirms that the issue can be reproduced with the Microsoft-provided WebView2APISample in Composition Mode, independent of our application's WebView2 integration.
Omer Mor (@OmerMor) Ambika Kunnath (@ambikakunnath) Chetan Pandey (@chetanpandey1266)
laiyierjiangsu commentedon Sep 15, 2026
My product has also been affected by this issue, and it is quite severe — it has resulted in a significantly degraded user experience. I believe the WebView2 team should take ownership of this problem and fix it, rather than attributing it to the underlying Chromium kernel. We are users of the WebView2 component, not of the Chromium kernel itself, so we rely on the WebView2 team to resolve issues that surface through this component. I would greatly appreciate it if you could escalate this issue to the WebView2 team and help ensure it receives proper attention. This is a serious problem that deserves prompt action.
Omer Mor (@OmerMor) Ambika Kunnath (@ambikakunnath) xystar2012 Chetan Pandey (@chetanpandey1266)
laiyierjiangsu commentedon Sep 15, 2026
Chetan Pandey (@chetanpandey1266) Omer Mor (@OmerMor)
Additional Request:
Please provide a native API for detecting when a Composition-hosted WebView stops processing mouse input.
In this state, the host continues to receive WM_MOUSEMOVE and mouse button messages, and SendMouseInput returns S_OK, yet the WebView content no longer responds to mouse or keyboard input. ProcessFailed is not raised because the renderer process is still alive and is not reported as unresponsive.
Without executing JavaScript or relying on page-side events, the host has no way to determine whether the input was actually processed by the WebView, nor can it safely decide when to recreate the WebView.
A native input-processing health event, an input acknowledgment mechanism, or a CompositionController responsiveness query would allow applications to detect this condition and recover by recreating the WebView.
wangqiang1588 commentedon Sep 16, 2026
same as #5715
1 remaining item
drysart commentedon Sep 16, 2026
Getting reports from users of my application that it's becoming unresponsive to mouse and keyboard (but otherwise the application is continuing to operate and DOM updates are displayed). My application does make use of
app-region: dragbut not in a way where CSS inheritance or element airspace overlap would come into play, so this may not only be an issue relating to CSS inheritance.laiyierjiangsu commentedon Sep 17, 2026
Yes, CSS inheritance isn't the root cause.
wangqiang1588 commentedon Sep 18, 2026
How to fix it ?
wangqiang1588 commentedon Sep 20, 2026
why?
callstack:
mgalla10 commentedon Sep 24, 2026
Our application has been impacted by this as well. Are there any updates on this? Is this something that we can expect might be addressed in future WebView2 runtime updates?
laiyierjiangsu commentedon Oct 12, 2026
Chetan Pandey (@chetanpandey1266) Is there any update about this issue?
In my option, [Bug]: Visual-DComp WebView stops responding while SendMouseInput continues to succeed
#5712 this bug is another problem, and has no relation with CSS inheritance on app-region . Please check .
chetanpandey1266 commentedon Oct 22, 2026
KHacker (@laiyierjiangsu) navneetrathi-msft is looking at the issue. He will update you by next week.
laiyierjiangsu commentedon Oct 26, 2026
navneetrathi-msft I reproduced this problem in the latest version 155.0.4283.62. This regression has a serious impact on the customer experience of our product. Could you give me some update asap?
laiyierjiangsu commentedon Oct 30, 2026
navneetrathi-msft Is there any update?
navneetrathi-msft commentedon Oct 30, 2026
Hello,
we will provide an update soon.
Working on this.
Thanks.
laiyierjiangsu commentedon Oct 31, 2026
navneetrathi-msft Thank you for your hard work . If you know which version will be updated to fix this problem , could you let me know ? I want to check it asap.
navneetrathi-msft commentedon Nov 3, 2026
Hello,
I checked, this is probably not the correct issue to track this as this was raised for a different reason, this github issue deals with css-inheritence for app-region drag and the issue bveing discussed here is different and relates more to this - #5712 (comment)
KHacker (@laiyierjiangsu) I will be closing this one and we can follow up on #5712 (comment)