Application.Current.OpenWindow() creates a redundant instance of WebView

[linkaiyu]

Description

if a window that has a contentpage that has a reference to a WebView as a member, when calling Application.Current.OpenWindow(), an additional instance of WebView is created by the runtime.

Steps to Reproduce

Here is a link to the repro:
https://github.com/xamcat/fid-protos/tree/main/src/repro_redundant_webview

Click the button "Click me to new WebView instance"
Observe one instance of WebView2 in Task Manager
When the WebView appears, click the button "Pop me up"
Observe the second instance of WebView2 in Task Manage

Link to public reproduction project repository

https://github.com/xamcat/fid-protos/tree/main/src/repro_redundant_webview

Version with bug

6.0.486 (current)

Last version that worked well

Unknown/Other

Affected platforms

I was not able test on other platforms

Affected platform versions

Windows SDK 10.0

Did you find any workaround?

no workaround

Relevant log output

No response

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[Eilon]

Hi @linkaiyu , the linked repro project either doesn't exist or is private. Can you check that it is publicly accessible?

In the meantime, I have a few notes on this per my understanding:

1. Each app that uses WebView2 will typically have at least two WebView2 EXE processes associated with it (I think one does the WebView stuff, and one monitors health maybe?). I don't think there's any control over this - it's just the normal behavior.
2. Once the main app closes, all associated WebView2 EXE processes will also close.
3. The WebView2 EXE processes in general I think live at least as long as the WebView2 control instance, and I think you can force disposing the WebView2 control to end all WebView2 EXE processes.
4. I'm not sure if having more WebView2 controls in an app necessarily causes more WebView2 EXE processes to be created.

[Eilon]

When I first launch the app I get one EXE as expected:

When I click the button to get a WebView, I then get seven WebView2 EXE processes created (a 'main' one, plus 6 extras):

When I click the popup button I get one extra WebView2 EXE process:

As far as I know, this is entirely expected for WebView2.

[Eilon]

After talking to @mikeparker104 some more, I'm starting to think there is some kind of bug here in .NET MAUI. When I created a pure Windows App SDK app with a WebView2 in it, each time I open a new window in the app I see some more WebView2 EXEs spawning, but then after I close the last window that uses WebView2, all the WebView2 EXEs are immediately terminated.

Here's what I did in my Win App SDK app:

1. Create new Win App SDK app
2. In MainWindow.xaml.cs change the existing methods to be this:

       private void myButton_Click(object sender, RoutedEventArgs e)
       {
           myButton.Content = "Clicked";
   
           Window window = new Window();
           window.Content = new WebView2() { Source = new Uri("https://microsoft.com") };
           window.Closed += Window_Closed;
           window.Activate();
       }
   
       private void Window_Closed(object sender, WindowEventArgs args)
       {
           ((WebView2)((Window)sender).Content).Close();
       }

3. Run the app
4. Click the button several times to create additional windows that each have a WebView2
5. Note in Task Manager that new WebView2 EXEs are spawned
6. Close all the sub-windows
7. Note in Task Manager that all the WebView2 EXEs are all gone now

But in a similar scenario in .NET MAUI in step (7) you still see some WebView2 EXE's lingering around

[linkaiyu]

Hi Eilon,
I will let @mikeparker104 add you to the repo as it is under a private repo for Fidelity.

To see the bug, you can set a bp at line 29 in /Platforms/Windows/TestWebViewHandler.cs

    protected override WebView2 CreatePlatformView()
    {
        _webView = new MauiWebView();   // line 29, set a bp to see this get called extra time when OpenWindow() is called.
        InitializeWebView2(_webView);
        return _webView;
    }

In the normal flow when a contentpage that contains webview is created and closed, this does not cause problem.

The problem is when the contentpage is moved inside an independent window (like a popup window), the OpenWindow() method creates a redundant instance which does not close when you close the popup window. You will see the webview count in task manager increase by one. if you repeat this sequence again, the webview count increases again.

[Eilon]

I do have access to the private repo.

I think I understand now what you're saying. It's perhaps not a general problem with the webview, but specifically to do with removing a control from one window and adding it to a new window? And you see CreatePlatformView called again, which is presumably why there are "too many" webviews?

I wonder, do you see this happen with any other controls, such as Button? I think if we can understand whether this is an issue specific to webview or general to all controls, or perhaps even an issue with how this app is doing things, that will help us resolve this.

[linkaiyu]

When the redundant instance of WebViewHandler and MauiWebView is created, other controls such as button is not redundantly created.
here is what memory dump looks like:

1. when the TestWebView and TestWebViewHandler is created and shown up in the main page for the first time:
   

00007ff9a06dd688 1 112 RedundantWebView.Platforms.Windows.TestWebViewHandler
00007ff9a06dcb70 1 648 RedundantWebView.TestWebView
00007ff9a0be3870 1 160 Microsoft.Maui.Platform.MauiWebView
00007ff9a01e0308 4 2336 Microsoft.Maui.Controls.Button

2. when the contentpage is moved to a popup window:
   

00007ff9a06dd688 2 224 RedundantWebView.Platforms.Windows.TestWebViewHandler
00007ff9a06dcb70 1 648 RedundantWebView.TestWebView
00007ff9a0be3870 2 320 Microsoft.Maui.Platform.MauiWebView
00007ff9a01e0308 4 2336 Microsoft.Maui.Controls.Button

there is an increase of TestWebViewHandler, and MauiWebView

3. when the pop up window is closed
   00007ff9a06dd688 2 224 RedundantWebView.Platforms.Windows.TestWebViewHandler
   00007ff9a06dcb70 1 648 RedundantWebView.TestWebView
   00007ff9a0be3870 2 320 Microsoft.Maui.Platform.MauiWebView
   00007ff9a01e0308 4 2336 Microsoft.Maui.Controls.Button

everything is the same as before the window close. This data maybe not reflect the true state of memory as they may must remain in memory even they are closed as GC has not really removed them from memory yet. So the 3rd count is not accurate

[linkaiyu]

@Eilon, while we want the WebViewHandler's CreatePlatformView() not to be invoked when application invokes Application.Current.OpenWindow() as it causes two problems:

1. it creates a redundant instance of the WebView and causes memory leak.
2. if we close the previous instance of webview, we look the context of the web page when we transit to a new webview

@mikeparker104 found a fix for the memory leak by invoking WebView.Close() in the DisconnectHandler() method, as demonstrated in this code:
https://github.com/xamcat/fid-protos/blob/main/src/repro_redundant_webview/ReproRedundantWebView/Platforms/Windows/TestWebViewHandler.cs

protected override void DisconnectHandler(WebView2 nativeView)
        {
            this.testWebView.OnExecuteJavascript = null;
            this.testWebView.OnLoadHtml = null;
            testWebView.Close();

            base.DisconnectHandler(nativeView);
        }

However, when testing the code in Fidelity's POC project, this DisconnectHandler() function is not invoked in the same flow.
Are you aware of any factors that could affect this behavior?