WebView2 fails to load in Office Add-ins, with different monitor scaling settings

[tiagoabreu]

Description
An Office Add-in with WebView2 rendering in a custom task pane stops working on displays with different scaling than the main display.

Added solution where problem can be replicated:
WordWebView2AddIn.zip

Version
SDK: 1.0.664.37
Runtime: WebView2 Runtime 87.0.664.75
Framework: WinForms
OS: Win10 1909, Word 2101 (Build 13628.20118)

Repro Steps

1. Download solution provided in the bug
2. Assuming you have at least two displays, go to Display Settings and change the scale of items on one of your displays so that it differs from your main display (e.g. set the main display to 100%, secondary display to 125%)
3. Make sure the Start-up screen in Word is disabled
4. Start Word from the add-in solution in the secondary display
5. Check if page is rendered and word is not frozen

Screenshots
Expected and what is displayed when opening Word on main screen:

Displayed when opening on a secondary screen (the application is frozen in this case) and also when start-up is enabled

Additional context
Also replicable in the latest pre-release version.

When having the startup screen (also called backstage) enabled, the Webview2 control does not render at all, despite the navigation happening in the background. That was verified only through debugging.

AB#31424281

[ozhanatali]

Same issue here. I'm using shared runtime, Windows 10 and latest office 365 build. Webview2 is installed. I can see that excel webview pings the backend but not running the frame. The addin works while sideloading on excel online

EDIT: I just created a new project on visual studio c#. It's working well with edge instance before converting to shared runtime. But after the same result :(
And the same addin works well on office web (while sideloading).
without shared runtime office addins means nothing and should be updated as soon as possible.

[jozefizso]

We have the same issue with CefSharp and WebView2 when they are used in Office add-in.

[chucklay]

Seems like I am hitting the same issue as ozhanatali - Shared runtime add-in loads without issue on any browser I try it in, but on desktop I get the same solid grey screen. OfficeAddins.log.txt also claims that the add-in loaded without issue.

[champnic]

Tiago Abreu (@tiagoabreu) Can you confirm that the only difference between the version that is working and not working is the different DPI on the second monitor? If the main monitor is a different DPI (125%) does it work? If the secondary monitor is 100% does it work? Your screenshots seems to show 2 different scenarios, so just trying to narrow the problem down a bit.

Others - Could you please let me know what SDK version and runtime version you are using? Does the issue still repro if you use the latest prerelease package and Edge Canary for the runtime?

[tiagoabreu]

It works if both monitors are set to the same DPI. If there is a difference in DPIs (e.g. 125% on the main monitor, 100% on the secondary) AND you are running it on the secondary monitor, it does not work. If you are running on the primary monitor, it works in any case.

[jozefizso]

The content will not render correctly anytime there are two monitors with different DPI settings and user will move the window between monitors.

It will also break when user changes the DPI while the application with WebView2 is open.

One if the issues is Office applications does not send the DPI changed event to task pane instances. Also, the Chromium/Edge rendering process is set to fixed DPI level which may be incorrect when monitors have different DPI settings.

[mancristiana]

I could also reproduce this behavior issue with:

• SDK version 1.0.721-prerelease
• Microsoft Edge WebView2 Runtime 87.0.664.74

I could only reproduce this issue when I had different scaling settings on my displays (100% and 125%) and opened Office applications with WebView2 in a task pane on my secondary display. When I set both my monitor and laptop display to the same scaling (e.g. 125%) it worked as expected.

[champnic]

Great, thanks so much everyone for the added detail! I've added this bug to our backlog to take a closer look.

[tiagoabreu]

Hello Nic Champagne Williamson [MSFT] (@champnic) ,

Can you provide feedback on this one? Currently we have no workaround around it and it renders Office with the add-in unusable in a multi-screen setup when using it on a secondary screen (with different DPI scale settings, as mentioned before).

[jozefizso]

We use WebView2 to display HTML content in a Task Pane in the MS PowerPoint.

When I open the PowerPoint and the Task Pane on a monitor with 125% DPI scaling and then I move the window to second monitor with 200% DPI scaling, the HTML content will pop out of its place in the Task Pane.

PS: In our implementation with CefSharp we had these same issues. We were able to fix them by setting DPI awareness for .NET threads each time our code was creating web view controls. These DPI awareness fixes does not work for WebView2.

[jozefizso]

Hi Nic Champagne Williamson [MSFT] (@champnic), this is the behavior of Edge WebView2 1.0.790-prerelease when running inside MS Office apps and the user drags the app from monitor with 150% scaling to monitor with 200% scaling.

The hit area is correct - as I move the mouse over the task pane, I can click buttons and HTML elements react to the mouse at the right position. The issue is with the content being rendered out of the web controls actual area.

Edge_WebView2.mp4