Webview2 VSTO Office Plugin: Meeting / Email window gets into freezing state while opening form (custom task pane)

[ManojPatelA]

Hello,

With Outlook plugin custom task pane and WebView2 control it seems a known issue where the form gets misplaced when you load the form on different monitor scaling #820

Along with this behaviour, I see one more issue where meeting / email window gets into freezing state as soon as form gets open. This behaviour is consistent and happens with just one monitor as well.

Steps to reproduce:
1. Keep your monitor scaling to 100% (recommended option)
2. Open outlook
3. Change monitor scaling to 125%
4. Open new meeting / email window and click on your plugin ribbon button
Consistently this makes meeting window frozen, this can easily happen when you work from home and office and have different resolution / scaling.

As per article Handle high DPI and DPI scaling in office solution workaround is to use Office DPI compatibility model however, this freezing issue still happens. With compatibility mode setting misplacing of the form issue gets resolved.

WebView2 runtime: 114.0.1823.79
SDK: 1.0.1823.32

Is there any fix / workaround for this issue ? If not what's the timeline for fixing out this issue? Is fix will be only available with OS win11 as per the above github article ?

Thanks,

AB#45893635

[novac42]

@ManojPatelA Thanks for reporting the issue. If possible may you share a sample app for us to repro?

[champnic]

@ManojPatelA You are right that this sounds like another DPI related issue. When are you creating the WebView2 control? When the addin is loaded, or only when the plugin button is clicked? If you were trying to display an existing WebView2 after the DPI change then that could be the source of the mismatch and failure. If so, could you try only creating the WebView2 when the button is clicked so that the WebView2 matches the DPI and awareness of the parent window?

[ManojPatelA]

@champnic I have tried both the ways creating wevvie2 control, while opening of window as well as clicking on the button getting exactly same result. Even I have added one winform button (on top of task panel along with WebView2 control) and on click of that button opening of Winform pop up with completely new webview2 control there as well it's the same issue.

[ManojPatelA]

@ManojPatelA Thanks for reporting the issue. If possible may you share a sample app for us to repro?

I have tried with my actual project as well as with small new add in both have exactly same result. Due to some setup issue I am unable to share but will do it soon. Thanks

[ManojPatelA]

@ManojPatelA Thanks for reporting the issue. If possible may you share a sample app for us to repro?
Here is the sample outlook plugin
SampleOutlookPlugin_Webview2_.zip

[champnic]

Thanks for sharing the sample, I'll try to reproduce the issue now. Are you seeing this on all versions of Windows, or only a specific one/range?

[champnic]

@ManojPatelA We believe this is a DPI mismatch issue when Outlook.exe, which is System aware, is somehow still responding and changing their DPI in a way that we can't detect and match in the WebView2 browser process HWND. We have work planned with #985 which would alleviate this issue altogether by removing cross-process HWND parenting. If you wanted to try out that work (it's not complete yet) you can set:
Environment.SetEnvironmentVariable("COREWEBVIEW2_FORCED_HOSTING_MODE", "COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL");

[ManojPatelA]

@ManojPatelA We believe this is a DPI mismatch issue when Outlook.exe, which is System aware, is somehow still responding and changing their DPI in a way that we can't detect and match in the WebView2 browser process HWND. We have work planned with #985 which would alleviate this issue altogether by removing cross-process HWND parenting. If you wanted to try out that work (it's not complete yet) you can set: Environment.SetEnvironmentVariable("COREWEBVIEW2_FORCED_HOSTING_MODE", "COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL");

[ManojPatelA]

@ManojPatelA We believe this is a DPI mismatch issue when Outlook.exe, which is System aware, is somehow still responding and changing their DPI in a way that we can't detect and match in the WebView2 browser process HWND. We have work planned with #985 which would alleviate this issue altogether by removing cross-process HWND parenting. If you wanted to try out that work (it's not complete yet) you can set: Environment.SetEnvironmentVariable("COREWEBVIEW2_FORCED_HOSTING_MODE", "COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL");

Thank you @champnic workaround you have suggested seems working as per our initial testing. Can you please suggest if it can have other implications with the outlook plugin as well as any other applications using WebView2 control ?

[champnic]

@ManojPatelA Glad it seems to be resolving the issue for you as well, that means our longer term fix is in the right direction.

The current downsides with this approach is that drag and drop won't work, and there are instances where if the window/task pane is moved, popups and dialogs may appear in the wrong place. For example, I noticed that in my test if I had a date picker, the picker popup would show up in the wrong spot after I moved the window around or moved it to a new screen.

[ManojPatelA]

@champnic Thanks! In my testing I observed right click context menu is not showing up in the right position but not sure how to replicate drag and drop with the custom task pane we have. Also, changing of the scale / move form from one monitor to different monitor than control gets misplaced however for that "optimize for compatibility" outlook setting helps.

Since this is environment variable, seems like it will impact all the applications on the machines where WebView2 control is being used (any office plugins + standalone apps). Please can you confirm that so we can understand the full impact. Also, can this setting impact any other web based / desktop based applications where WebView2 is not being used ?

[ManojPatelA]

@champnic one more observation in my testing, Ctrl + A; Ctrl + C; Ctrl + V stopped working on the UI form with this environment variable setting. Shift + Home/End works to select the text. Any fix/workaround you can suggest for this one ? Thanks!

[champnic]

@ManojPatelA I don't think we were aware of the Ctrl+A/C/V issues, I'll make sure we're tracking that as we work further on this feature. Offhand I'm not sure why that would be happening.

The environment variable would be set by your add-in and would only affect the current process. However, for add-ins that would mean the Office/Outlook process, so any other WebView2's created by other add-ins or Office/Outlook could be affected. This is probably mostly mitigated by setting the variable, creating the WebView2, and then unsetting the variable. The environment variable wouldn't have any affect on other apps/processes using WebView2.

[champnic]

I just tried and was unable to reproduce the issue with Ctrl+A/C/V - those seem to work fine in my sample.

[ManojPatelA]

Thanks @champnic are you having VSTO based outlook plugin ? It's inconsistent actually but most of the time I am able to replicate. When remove that environment variable, restart outlook it starts working consistently. Tried on multiple machines and getting same result.

[ManojPatelA]

@champnic just to add, I am able to reproduce this issue with the sample VSTO Plugin I have shared above. That plugin launches just one random website which has search box there Ctral+A/C/V doesn't work with the environment variable. Without that it works fine. Thanks!

[champnic]

Ah I only tried once or twice, so if it's intermittent that's probably why I didn't see it.

[ManojPatelA]

@champnic Is there any workaround for the same ? Today I have observed one more issue where all controls of the form becomes non clickable.
Use case:

1. open email/meeting window
2. don't click anywhere else just directly on the ribbon menu
3. Wait for form to load without clicking anywhere and then try to do operation on the form.
4. If you click on outlook window anywhere issue gets resolved.

Please note if we set environment variable at account level then this issue is inconsistent and if we set it with process (through plugin code only) it becomes consistent.

[champnic]

@ManojPatelA Is that new issue in WebView2, or just Outlook in general? If WV2, could you open a new issue in this repo for it and ping me?

[ManojPatelA]

@champnic This issue is after setting up the environment variable as a workaround for the freezing issue. After setting up that environment variable below two issues I observed.

1. Ctrl+A/C/V stopped working
2. Form controls become non-clickable till the time you focus on outlook window and then go back. [My previous message has more details about exact steps]

[champnic]

@ManojPatelA Can you see if adding the command line parameter "--edge-webview-no-dpi-workaround" resolves the issue (with the previous regkey state)?

[ManojPatelA]

@champnic do you mean apart from adding the environment variable I add this command line parameter ? Please can you confirm how exactly I can add command line parameter ? Is this while initializing it set any option ?

[champnic]

Yes. You can set it using AdditionalBrowserArguments property when creating your CoreWebView2Environment:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environmentoptions.additionalbrowserarguments?view=webview2-dotnet-1.0.2045.28#microsoft-web-webview2-core-corewebview2environmentoptions-additionalbrowserarguments

Or use the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environment.createasync?view=webview2-dotnet-1.0.1293.44#remarks

Or use the reg key:
[{Root}]\Software\Policies\Microsoft\Edge\WebView2\AdditionalBrowserArguments "Outlook.exe"="--edge-webview-no-dpi-workaround"

[champnic]

@ManojPatelA I've finished validating a fix on our end and we are checking it in today. You will be able to test it using the Canary runtime tomorrow, and it should deploy in the next 117 stable update next week.

[ManojPatelA]

@champnic great, Not sure I will be able to use Canary runtime but surely with 117 runtime. So fix is with runtime so package upgrade is not needed in the code ?

[champnic]

That's right - the runtime will automatically upgrade and no change will be necessary from IT, app, or Office side.

[ManojPatelA]

Thank you @champnic , can you please confirm if this fix will resolve #820 [misplacing of the form with scaling] as well ?

[champnic]

This is now fixed on Canary versions 119.0.2132.0+. We are now working to deploy it to 118 and 117 versions as well later this week.

#820 is large. Can you point to a specific comment or add repro steps/description here? The intent of this change is scoped to undoing the recent regression, not fixing every issue with WV2 in VSTO. #985 is tracking the feature enhancement that will likely resolve that.

[ManojPatelA]

Thanks @champnic I am referring this comment #820 (comment)
It's about HTML form from custom task pane gets misplaced when you move your window from one monitor to another which has different scaling.

[ManojPatelA]

Hello @champnic, seems this issue is not yet fixed. I am able to reproduce this issue consistently with the sample I have shared above as well as with the other outlook plugins. Release note of webview2 nuget package# 1.0.2088.41 has this issue listed as a fix however, with upgrading library as well (as such not needed as you mentioned above as fix is with runtime) issue is there. Please can you look into this.

[victorhuangwq]

@ManojPatelA thanks for your concern - this issue is closed already, and your problem isn't the same as the original issue you posted. Could you create a new issue so that we can track that there?

[champnic]

@ManojPatelA We used this issue to track a regression due to passing compatibility flags needed to workaround some issues in #820. I believe your existing issue is being tracked by #820 and/or #985, which will both be resolved by an upcoming change. I'll reach out when we have that checked in and available to validate with prerelease runtimes.

[ManojPatelA]

@ManojPatelA thanks for your concern - this issue is closed already, and your problem isn't the same as the original issue you posted. Could you create a new issue so that we can track that there?
@victorhuangwq thanks, how exactly you are saying my problem isn't the same as the original issue I have reported ? I am seeing exactly same issue with the steps I have provided. It can be possible technically it's different for you but for me and others it's the same issue. I am really not sure raising new issue would really help unless you explain the difference.

[ManojPatelA]

@ManojPatelA We used this issue to track a regression due to passing compatibility flags needed to workaround some issues in #820. I believe your existing issue is being tracked by #820 and/or #985, which will both be resolved by an upcoming change. I'll reach out when we have that checked in and available to validate with prerelease runtimes.

Thank you @champnic for your response. Looking forward to try out with the updated runtime version.

[champnic]

Hey @ManojPatelA - The runtime change has been checked into prerelease channels. Can you try using the environment variable again against any runtime 121.0.2229.0+ (such as the current Edge Canary):
Environment.SetEnvironmentVariable("COREWEBVIEW2_FORCED_HOSTING_MODE", "COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL");

Let me know if you are still running into the issue you saw earlier.
@johna-ms FYI