-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebView MAUI WinUI Memory Leak #20283
Comments
Consider checking out my memory toolkit designed to address these sorts of issues: https://github.com/AdamEssenmacher/MemoryToolkit.Maui |
We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process. |
Hi, I opened a duplicate issue that was closed, so I report here some information: After n page changes, Task Manager reports n WebView2 tabs related to the app, but Visual Studio memory report does not indicates the massive memory increase |
Multiple windows each contains the webview also have this issue after window get closed, I raised another new issue #22972 |
@davide-cavallini for now, can you do something like this in your protected override void OnDisappearing()
{
base.OnDisappearing();
webView.Handler?.DisconnectHandler();
} (I put This seems to solve the issue in your sample: |
Fixes: dotnet#20283 Fixes: dotnet#22972 Context: https://github.com/davide-cavallini/webview-winUI-maui-leak The above sample on Windows was leaking because it does the following: 1. Your app has a single `Window` 2. Navigate to a page with a `WebView` 3. Navigate away Because the `Window` remains alive, `WebViewHandler` subscribes to `Window.Closed` which keeps a reference to the `WebView` and keeps it alive indefinitely. I was able to reproduce this in a test, that keeps the `Window` alive before calling `AssertionExtensions.WaitForGC()`. The solution was to move the `Window.Closed` subscription to the `WebView2Proxy` nested class. This makes sure that the `WebView`, its handler, etc. can be collected *before* the `Window` is closed. I also found a secondary issue while debugging, if you call: webView.Close(); // MauiWebView or WebView2 If `CoreWebView2` is not initialized, it will throw a C++ exception. We can instead do: if (webView.CoreWebView2 is not null) { webView.Close(); }
Description
Each time a "Webview" tag is added in a Page or ContentView, the memory allocation is not freed by the garbage collector.
Steps to Reproduce
No response
Link to public reproduction project repository
https://github.com/davide-cavallini/webview-winUI-maui-leak
Version with bug
8.0.6
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
No response
Did you find any workaround?
The current workaround is to declare the webview in the code behind as static then changing its source binding each time the page/view is navigated.
In that way the leak happens only the first time and the memory allocated still the same.
Relevant log output
No response
The text was updated successfully, but these errors were encountered: