WebView2 control is not visible after changing the parent window

[DominikPalo]

Description
We are migrating our PowerPoint integration from CefSharp (a different Chromium-based webview control) to WebView2 and we have bumped into an issue when trying to change the parent window of a window with WebView2 control inside.

The way how our integration works is that we create a new WinForms window containing a WebView2 control and then during a slideshow, we occasionally cover the slideshow window with our WebView2 window (to "replace" the content of the presented slide). But, before we display that window, we need to change the parent window of our WebView2 window to the PowerPoint slideshow window (by calling the function SetParent with HWND of the PowerPoint Slideshow window) - so apps like Zoom or MS Teams stream also our WebView2 content while streaming just the PowerPoint slideshow window.

Unfortunately, it looks that the WebView2 WinForms control (unlike the CefSharp WinForms control) is not compatible with that solution: after changing the parent window, we can see just the empty WinForms window - the WebView2 control is not visible (although the embedded web is loaded).

Version
SDK: 1.0.790-prerelease
Runtime: 88.0.705.74 (Evergreen Bootstrapper)
Framework: WinForms
OS: Win10

Repro Steps

1. Create a WinForms window with a WebVew2 control inside
2. Change the parent window of that window using the SetParent function from Winuser.h to another (already visible) window
3. Show the WinForms/WebView2 window
4. Observe, that the parent window is covered by the empty WinForms/WebView2 window (the WebView2 control is not visible)

Additional context
The entire integration is built as a COM add-in (so it is running from the PowerPoint process).

AB#26124929

[pagoe-msft]

@DominikPalo

Thanks for submitting this issue! I've added it to our backlog and the team will investigate this.

[champnic]

We specifically did work to enable reparenting of the Winforms control, so I think this may be a bug or regression.

@DominikPalo Which HWND specifically are you changing the parent to be the slideshow window? Are you able to try changing the Parent property of the WebView2 Winforms control and see if that works?

[DominikPalo]

The main issue was that I was calling the SetParent method too early (before EnsureCoreWebView2Async)... after moving the SetParent call to the CoreWebView2InitializationCompleted handler, WebView2 is finally rendered, but I'm still not able to set the WebView2 window as a PowerPoint child window - SetParent now fails with ERROR_INVALID_STATE error and according to https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows#common-pitfalls-win32 the issue is caused by different DPI awareness modes.

Update: I've just discovered that if I didn't open a PowerPoint task pane with another WebView2 control instance before opening the window which should be hosted under the SlideShow window, everything works fine (I'm able to change the parent window).

Unfortunately, we need to use WebView2 in both places - in the task pane and also as a separate window hosted under the SlideShow window.

To summarize:

Scenario A:

1. Open PowerPoint
2. Open a task-pane with WebView2 control
3. Start a slideshow
4. Open a new window X with WebView2 control
5. Try to change the parent of the window X to the PowerPoint slideshow window
6. SetParent fails with ERROR_INVALID_STATE (the main msedgewebview2.exe has the same DPI awareness mode as the POWERPNT.EXE process - System Aware, so it should work)

Scenario B:

1. Open PowerPoint
2. Start a slideshow (without opening a task pane)
3. Open a new window X with WebView2 control
4. Try to change the parent of the window X to the PowerPoint slideshow window
5. SetParent works fine (although the main msedgewebview2.exe has a different DPI awareness mode compared to the POWERPNT.EXE process - System Aware vs. Per-Monitor Aware). This is very strange because according to the MS documentation, the SetParent should work in scenario A and not in scenario B...

[jamesoli]

@DominikPalo New APIs in Windows 10 1607 and above allow creating windows with different DPI awarenesses than the process creating it. I wonder if that's what's happening here. I'm not quite sure how you are getting the HWNDs to parent to so can you please check the DPI awareness of the HWND you are parenting to in both scenarios using the following API?

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowdpiawarenesscontext

[DominikPalo]

#985

@DominikPalo New APIs in Windows 10 1607 and above allow creating windows with different DPI awarenesses than the process creating it. I wonder if that's what's happening here. I'm not quite sure how you are getting the HWNDs to parent to so can you please check the DPI awareness of the HWND you are parenting to in both scenarios using the following API?
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getwindowdpiawarenesscontext

Thank you,

because it is not possible to use the SlideShowWindow argument from the Application.SlideShowBegin event handler (that is a known PowerPoint bug ), I'm getting the HWND of the slideshow/expected parent window using this workaround:

/// <summary>
/// Class name of the window with slide show content in PowerPoint 2010 and newer.
/// </summary>
public const string PowerPoint_SlideShowScreenName = "screenClass";

private void OnSlideShowBeginEvent(SlideShowWindow window)
{
    // We can't use window.HWND, it fails with:
    // System.Runtime.InteropServices.COMException HResult=-2147352573 Message=Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND)) ErrorCode=-2147352573
    // See: https://github.com/NetOfficeFw/NetOffice/issues/103 and https://github.com/NetOfficeFw/NetOffice/issues/140

    // WORKAROUND (using https://www.pinvoke.net/default.aspx/user32.FindWindowEx)
    var slideShowWindowHwnd = NativeMethods.FindWindowEx(IntPtr.Zero, IntPtr.Zero, PowerPoint_SlideShowScreenName, null);

    var slideShowWindowDpiAwarenessContext = NativeMethods.GetWindowDpiAwarenessContext(slideShowWindowHwnd);
    var slideShowWindowDpiAwareness =  Utils.GetAwarenessFromDpiAwarenessContext(slideShowWindowDpiAwarenessContext);
    
    var threadDpiAwarenessContext = this.NativeMethods.GetThreadDpiAwarenessContext();
    var threadDpiAwareness = Utils.GetAwarenessFromDpiAwarenessContext(threadDpiAwarenessContext);
    
    var slideShowChildWindowWithWebView2 = new SlideShowChildWindowWithWebView2(slideShowWindowHwnd);
}

in both scenarios, the resulting awareness modes (slideShowWindowDpiAwareness and threadDpiAwareness) are set to SYSTEM_AWARE.

But, the window which I want to set as a child window of the slideshow window (and which is hosting the WebView2 control) has DPI mode set to UNAWARE in Scenario A and SYSTEM_AWARE in Scenario B (not sure why).

SlideShowChildWindowWithWebView2:

public partial class SlideShowChildWindowWithWebView2 : Form
{
    private IntPtr SlideShowWindowHwnd { get; set; }

    public SlideShowChildWindowWithWebView2(IntPtr slideShowWindowHwnd)
    {
        this.SlideShowWindowHwnd = slideShowWindowHwnd;
    
        InitializeComponent();
        this.InitializeAsync();
    }
    
    private async void InitializeAsync()
    {
        var webView2Environment = await WebView2Configuration.CreateEnvironmentAsync();
        await this.webView2.EnsureCoreWebView2Async(webView2Environment);
    }
    
    private void webView2_CoreWebView2InitializationCompleted(object sender, CoreWebView2InitializationCompletedEventArgs e)
    {
        NativeMethods.SetParent(this.Handle, this.SlideShowWindowHwnd); // this method fails in Scenario A
    }
}

I checked also the COMAddin.Application.ActiveWindow (which is passed to the ICTPFactory.CreateCTP method while creating the task pane hosting a WebView2 control) and its awareness mode is also set to SYSTEM_AWARE.

So, I'm not sure why the DPI awareness modes of my WebView2 subprocesses differs in scenario A vs. B.

I also tried to enforce the DPI awareness mode by setting/overriding the --embedded-browser-webview-dpi-awareness argument:

public static async Task<CoreWebView2Environment> CreateEnvironmentAsync()
{
    var options = new CoreWebView2EnvironmentOptions($"--embedded-browser-webview-dpi-awareness=1");
    return await CoreWebView2Environment.CreateAsync(null, UserDataFolder, options);
}

but it didn't help - WebViewLoader.dll overrides this argument with its own value later ...

Maybe there is a way how to make WebView2 subprocesses isolated? So the WebView2 control in the task pane would have its own WebView2 subprocess and also the WebView2 control in the SlideShow child window will have a different WebView2 subprocess - this would probably help to solve the issue.