Extra uncontrollable zoom factor applied to WebView2 content on about 1% of systems.

[dev-3mensio]

Description We build a .net 6 Winforms application that embeds WebView2 for UI. We use the transparency feature to make part of webview2 transparent. On a small minority of systems, it happens that webview2 applies an extra zoom factor (often around 8 - 15%) so that the pixel coordinates used in WebView2 do not match the winforms pixel coordinates. The zoom factor is constant for that particular system.

As for High DPI/display scaling: our software uses the primary monitor DPI as active when the app is started. On affected systems, the issue happens 100% of the time, independent of what monitor is used.

For many applications such a zoom, when applied consistently, may not be very noticable, but our software tries to align a window with coordinates retrieved from the Javascript running in the browser, so this causes the UI to be misaligned. We have patched our software to measure the offsets and apply a correction, but we would prefer that WebView2 is fixed.

The browser Zoom factor is reported as 1.0 when the sofware starts on all systems.

Version For the affected users, it was reported for from the first time they used the system. At that time, they were using version 112 and 115, but this was upgraded since with no effect on the behavior. We are on .net 6.

Regression No regression. As far as we can tell this behavior is consistent across restarts and upates.

Repro Steps Reporduction requires an affected system. So far only customer systems that we don't have direct access to expose this behavior. Preparation: On an affected system, set monitor Dpi to 96.

Create a webview2 instance in a window with a client area of 500x500 pixels. Load an html page and click the bottomright corner of the page and pass it's value to C#. Rather than 499x499, the location is reported back as 452x452 or similiar. The difference can not be reset .

Screenshots Sorry don't have any.

Additional context Thei issue is not related to trackpad zooming, when that is used the zoom factor is correctly changed.

AB#47173813

[johna-ms]

Interesting issue, I don't think we've had other reports of this. It's unfortunate there aren't screen shots, I have some questions to better understand the scenario.

Is the content scaled incorrectly in the not working scenario as well? Or is it just that the webpage is reporting incorrect bounds?

Is there any impact on the value of CoreWebView2.Bounds? Is it possible to base your size logic off of the actual WebView bounds instead of the javascript?

Any chance you have OS build info for the affected systems? And/or GPU information? If there's any pattern in this data that would be helpful.

[dev-3mensio]

The web content by itself is rendering self-consistent and complete. But it is larger than specified and the virtual pixels do not match the screen pixel DPI. For instance, when I ask WebView2 via javascript how big the window is, it reports 800x600 when it is actually 1000x750. All of the UI is rendered too large. The webview2 scales the UI by an arbitrary factor. This happens on a handful of systems. They are customers's machines that we have very limited access to. We use use javascript mouse and html control locations to align content between WebView2 and DirectX, and this fails when this issue happens.

Our app is an image viewer app with HTML controls in a WebView2 that covers the entire screen. We have a DirectX viewport in the middle. It is behind a transparent rectangle in the WebView2. We do it like this because sometimes HTML UI be on top of the viewer. For aligning the content, we ask the WebView2 for coordinates in terms of (virtual) pixels. We are aware of High DPI on windows and we test with various DPI. We are not DPI change aware, but the problem also happens with a single screen with a fixed DPI.

I do have a screenshost and some details. The screenshot is redacted so it looks a little ugly. The WebView2 is a winforms control, and it is drawn at the correct location with the correct bounds. When we ask it for the size of the transparent rectangle for our own content, that rectangle not in the expected window coordinates, so our viewport is offset and scaled as you see in the screenshot.

We don't allow the WebView2 to zoom, it reports a zoom factor of 1.0.

The details of this particular system are:

CPU name:                  11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
CPU Cores:                 8 Logical
Display(s):                1920x1080 (primary); 144 dpi
WebView2 version:          114.0.1823.82

.NET runtime(s):
Microsoft.AspNetCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Uptime (hours):            0.6  

Videocards:
- Intel(R) Iris(R) Xe Graphics, version 27.20.100.9621, 1024 MB

OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.19044 N/A Build 19044
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Member Workstation
OS Build Type:             Multiprocessor Free

It is also seen on a different Iris XE GPU but also on a laptop combining NVIDIA RTX A3000 and an Intel(R) UHD integrated graphics. Most common OS is Windows 10 Enterprise 19044, but I have also an example of Windows 10 Pro 10.0.19042.

We have a workaround: on affected systems, we configure it to apply a scale factor based on the measured zoom factor (by comparing javascript pixel size with WebView2 pixel size. But I think this is a brittle solution, and it also causes the UI scale to be different compared to normal installs.

Oh, and the offending systems are in found in at least the USA, UK and greece, so it does not appear to be localization related.

[johna-ms]

Interesting, there doesn't look to be much of a pattern in OS or GPU. Shot in the dark, but if you have an affected system to experiment with, you can try adding an additional browser argument '--disable-gpu' to rule out if it is a hardware acceleration problem. One way you can do this is by modifying this regkey: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\WebView2\AdditionalBrowserArguments. Add your_app_name.exe as a string value and set it to --disable-gpu.

Thanks for the detailed response, I'm adding this to our backlog to investigate further

[johna-ms]

This could also be a text scaling issue. You should check if changing text size in the system settings causes the bug to repro for you

[dev-3mensio]

The text scaling is almost certainly the issue! If I change that setting on my system I get exactly the reported behaviour! I will go and reach out to someone affected by the issue to doublecheck. Thanks! I will report back later, but in the meantime, if this is the actual issue, is it expected that WebView2 will continue to work as it does now? In the sense that the text size setting will change the mapping between screen pixels and webview2 "pixels"?

[dev-3mensio]

Hi, i have confirmation that this is indeed a setting that was adjusted for one of the complaining customers. For now I consider this issue "resolved" in the sense that we understand what the behaviour comes from.

Many thanks for looking into this!

For the record I am fine with closing this issue.

Final note: I understand that this is a effective way to adjust the text size. For us, it would be helpful if WebView2 exposes an "Effective Zoom Size" read only property (combining all scale factors that change the HTML pixel to display pixel ratio) that we can use from code would already help.

[johna-ms]

@dev-3mensio thank you for bringing this to our attention. Good and bad news, we do expose the scale value you're looking for, but apparently not on our .NET control, it's the rasterization scale. I'm closing this and tracking internally that we need to investigate exposing RasterizationScale on our .NET controls.

You should be able to work around this using these APIs to get the system scale factor and text scale factor though the latter API requires taking a dependency on WinRT. Hope this helps!