[Problem/Bug]: Using touch screen and mouse click in combination does not work.

[knuterik91]

What happened?

My Winui3 and webview2 app is used by users that uses both touchscreen and mouse click in combination. So whenever a touch event is happening, mouse click does not work / is not registered in the webview.
No errors in webview console or in visual studio. If we re-size the window, then mouse click works again.
This started happening 12th of february.
We are trying to rollback to a later version of edge to see if the issue goes away, but for time being we havent been able to do so.

Any help appreciated.

Importance

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

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

133.0.3065.69

SDK Version

1.6.250205002

Framework

WinUI3/WinAppSDK

Operating System

Windows 10

OS Version

19045.5371

Repro steps

I've created a repository that easily reproduce the issue. https://github.com/knuterik91/WinUi3WebView2TouchAndMouseIssue/tree/main The application also logs mouse and touch events in the ui.

Need a computer with a touchscreen. 1.Clone the repo and follow the readme. 2.run the application 3. Click on the button with your mouse, and see that current time and date is shown and gets updated for every click. 4. use the touchscreen and touch inside the webpage. 5. try to click the button again. ** does not work **

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

[MarnorBDG]

We are facing the same exact problem affecting 200+ customers. It also seems that win+E or opening explorer allows normal mouse input again until touch is used.

[astrh]

Same problem here affecting an app of 2k+ customers, I've created a demo myself in https://github.com/astrh/WebView2TouchIssue/tree/master including touch simulation so you won't need a touch screen to see the issue

[erlisav]

We are facing the same exact problem affecting 200+ customers. It also seems that win+E or opening explorer allows normal mouse input again until touch is used.

Same problem here affecting an app of 2k+ customers, I've created a demo myself in https://github.com/astrh/WebView2TouchIssue/tree/master including touch simulation so you won't need a touch screen to see the issue

Out of curiosity, what kind of touchscreen are your customers using?

[RobertSmits]

What I have found is the issue does not happen on WebView2 Runtime version 132.0.x.x but does happen on version 133.0.x.x, all other things being equal.

[lvendramini]

We are experiencing the same issue as well effecting about 150 users. How can I downgrade to 132.0.x.x? I tried from https://developer.microsoft.com/en-us/microsoft-edge/webview2/?cs=3815048149&form=MA13LH but it only goes to 133.0.x.x.

[Jamison-Jia]

Facing the same issue and i can confirm that @RobertSmits 's soluton works fine on my end. Anyone (@lvendramini ) wanna to have a try, please folow below steps:

• Download the specfice version of WebView2RunTime from this repo- https://github.com/westinyang/WebView2RuntimeArchive/releases (Graet thanks to the author's collecton work with his remarkable foresight, enablling us to still have a way to downlaod older versions)
• Follow this documentation to distribute the specific version to your App (https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution?tabs=dotnetcsharp#details-about-the-fixed-version-runtime-distribution-mode)

Anyway, it's just a temproray workaround and hope there wourd be a quick fix from MSFT/WebView2 team.

[Herrick19]

We also have the problem on an app used by 5k users is there an ETA to have this fixed ?

we can reproduce on the sample MS project for WinUI3 and Webview2

[Naashkyr]

Same issue as everybody else has mentioned here.

[Herrick19]

Out of curiosity, what kind of touchscreen are your customers using?

We can reproduce on a Microsoft Surface easily

[Dyssling]

Also affected by this. However, the solution provided above (downgrading to 132.0.x.x) works for now, but it's not ideal since it requires a fixed runtime which takes up a lot of space.

[richardhauer]

I have this issue as well. Blazor Hybrid in MAUI (net 10.0 Preview 3) My WebView2 version is 135.0.3179.73 - so apparently this is still happening since 133.x There are no touch capabilities on my machine at all. Just a normal desktop with 3 normal 27" screens.

I do, however, have a Logitech MX Master 3 mouse with both a center-button scroll wheel and a "thumb position" horizontal scroll wheel.

Vertical scrolling with the center-wheel is fine ... until I use the thumb wheel to horizontal scroll. After that the center-wheel is now "locked" to horizontal scrolling as well.

I have found that resizing the window of the app in the horizontal plane (i.e. changing the width of the window) will sometimes restore normal scrolling behaviour (as a bit of a workaround).

Using SHIFT+center wheel to horizontal scroll does not cause this behaviour. It only gets "stuck" when I use the thumb wheel to initiate the scroll.

Interestingly I do not see the same behaviour in Edge browser. I would have thought both were using the same version of the WebView2, no ?

Edit I have tried adding a few Chrome environment switches, but to no avail. Here's where I'm up to:

private void BlazorHost_BlazorWebViewInitializing( object sender, Microsoft.AspNetCore.Components.WebView.BlazorWebViewInitializingEventArgs e )
{
	e.EnvironmentOptions ??= new();
	e.EnvironmentOptions.AdditionalBrowserArguments = "--disable-features=OverscrollHistoryNavigation,msExperimentalScrolling,ElasticOverscroll --touch-events=disabled";
}

This isn't doing anything for me so going to abandon this path now. I thought perhaps disabling touch might work as that seems to be the main part of this thread, where I'm getting the same behaviour without any touch capability on my system at all.

[thirstyape]

Any news on a plan to fix this?

[richardhauer]

@thirstyape Seems like a pretty serious problem, but there's 800+ open bugs on this repo going back to 2019, so I'm going to guess they are a little resource-constrained. I wouldn't hold your breath for a fix.

[koenvd]

This issue is now reported as well by several of our users of our app (WinUI3.0) on multiple devices like Microsoft Surfaces and Lenovo ThinkPads.

Is this on the radar @champnic ?

[char8t]

There are already many other issues that are somewhat or directly related: https://github.com/dotnet/maui/issues/16251 https://github.com/dotnet/maui/issues/25612 https://github.com/MicrosoftEdge/WebView2Feedback/issues/3685

[koenvd]

cc @sivMSFT as well.

Based on your role description I hope you can weight in here ...

[koenvd]

Any update here @sivMSFT ? Is this being looked at?

[joshtorrisicanary]

Hello @sivMSFT any update on this?

[sivMSFT]

Hi @koenvd & @joshtorrisicanary, our team is actively investigating the matter and will provide updates as soon as we have any progress to share.

We appreciate your patience and understanding.

[Navdeep-ss]

It was a runtime issue and has been fixed in version 138.0.3320.0 (Official build) canary (64-bit) Folks can try it out using latest webview2 canary runtime.

[applefanbois]

This is not very useful information. The only thing you are telling us is that one day it may work. When I look at what has been fixed, it does not even look like the same problem. Do the user need to update the runtime, does the SDK needs to link to that new runtime??? Do I need to recompile my app with a new version of SDK?

In the meantime, all our users have deactivated their touch screen driver. By the time it is fixed everybody will have a disabled touch screen and nobody will care.

That is what happens when instead of having 1 SDK and platform (like modern OS : Android and Apple), you have 100 different SDK splinted into smaller components scattered across the 4 winds. Instead of making tons of crappy SDK and runtimes, MS should focus on just 1 that actually works.

[richardhauer]

@applefanbois

Most people use the WebView2 through the "evergreen" distribution, which gets updated with Windows/Edge. This gets rolled out to users somewhat silently so it should just start working for people at some point, when it moves past the Canary phase.

Looking at Edge's Help->About my build is currently at 136.0.3240.76

It's possible for your app to package a specific version of WebView2, though I think this is generally discouraged. If you wanted to get this version out to your users faster, assuming it does actually fix the problem, you could package this Canary build and ship it. Bear in mind that Canary builds don't generally have the same testing rigour applied that GA versions have, but it might get you out of a hole, at least until v138 goes GA.

See here for more information: https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution?tabs=dotnetcsharp#details-about-the-fixed-version-runtime-distribution-mode

[applefanbois]

@richardhauer

That is a fantastic answer. So I have nothing to do but wait for the update to be automatically installed on the user computers.

I was puzzled because in the past, the fixes require updating the SDK version, but not this time.

[richardhauer]

@applefanbois one of the benefits of utilising a platform-component... at least that's how I understand it to work.

We can look at the advertised release schedule, https://learn.microsoft.com/en-us/deployedge/microsoft-edge-release-schedule#release-schedule

It suggests "week of 26 June". The workaround (resizing the window) is probably enough instruction for users to hold them for a month... depends on your use-case.

[armendimeri]

Also having the same issuse in the last couple of months clients with touch screens cant use mouse after using any kind of touch input

[applefanbois]

My fix to deactivate the touch screen driver is probably the best option for people who don't use the touch screen much.

[martyandreas]

138.0.3351.55 The 26-June-2025

The update is here but i still have Mouse freezes in Maui Webview2.

I only have to update the Edge Browser or someting also in the Maui Project?

[applefanbois]

Maybe it works if you format your SSD and re-install windows? I seriously hope that there is something else to do for this fix to work. Cannot try it because I don't have such a device and our users already have deactivated their touch screen driver.

[applefanbois]

We did edge://settings/help in MS Edge browser and updated to v 138. Yet inside our app, the webview2 version stays to version 137.

There are no ways tu update to 138 for the webview.

I bet we will have version 138 in a webview2 in a few months. I don't understand why MS does not allow to update webview2 for 3rd party apps.

You can use : CoreWebView2Environment.GetAvailableBrowserVersionString(); to get the real version of the webview2 your app is actually using.

[martyandreas]

@applefanbois My version in the Webview is 137.0.3296.93

It's getting really ridiculous with Microsoft. Then they more or less force you to update from Xamarin to Maui and a lot of things just don't work properly. You spend so many hours trying to get everything to work with workarounds and in the end not everything works and you have to keep putting the customer off. The problem is that the app is used by service technicians who use touch and mouse. I can't tell them to deactivate touch.