-
Notifications
You must be signed in to change notification settings - Fork 690
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
WebView2 lifecycle #4752
Comments
WebView2.Close() can be used to immediately destroy the underlying CoreWebView2 and associated Anaheim objects. Otherwise, the timing of cleanup is dependent on garbage collection scheduling (for C#). Note that WebView2 UIElement leaving the live tree does not itself cause CWV2 to be destroyed, though (for C#) assuming no outstanding references, it should happen shortly via WV2 destruction. Also, making the WV2/CWV2 invisible does not imply cleanup of the CWV2 object. The behavior you are seeing could be due to the underlying CoreWebView2 lifetime policies. When a CWV2 instance is deinitialized, the browser process that serviced that "tab" can be kept alive to service other tabs, in which case some of the mssedgewebview2.exe instances will stay around. This sharing is based on whether the CWV2 instances specify the same UserData folder - more info here.. Xaml WebView2 automatically sets UserData folder based on app install location, so, for example, having two instances of the app running could lead to the observed behavior. Can you confirm there are:
|
@DmitriyKomin Thank you for looking into this and explaining. Calling Close() works (don't know how i missed that, sorry). I have added Close() to the unload event of my pages and that reliably closes the tabs and terminates webview2. But, I can confirm that if I don't call Close() on the WebView2, the tab stays alive for me. I can confirm that no other instances of the app running. And no other WebView2 instances are currently in the app. I have simplified the visual tree to only be a window with a frame inside that loads various pages, one of which contains a WebView2. I have removed any interaction with the WebView2 besides calling If I navigate between the various pages repeatedly also loading the WebView2 containing page I get an additional "tab" each time (I tested up to 48 tabs). I am testing in Release mode on Reunion 0.5 stable with dotnet 5.0.5 - Waiting 10 minutes or putting memory pressure on my laptop (Loading 16 tabs in Firefox and Google Chrome each) did not result in the disposing of the WebView2. I can create a sample project for you, but the same behavior is also occurring if I browse the WinUI 3 Controls Gallery from the Microsoft Store. (The WebView 2 page). |
Thanks, Have you tried calling GC.Collect() in Page.OnNavigatedFrom handler? It does seem strange that waiting 10 minutes + applying memory pressure to the system didn't trigger GC... One other idea - looking at https://github.com, that is a very complex webpage with live animations and a bunch of video elements... I wonder if some of those are keeping CoreWebView2 alive? Does the problem repro with some trivial webpage (for example http://www.brainjar.com/java/host/test.html)? |
Hi, GC.Collect() was very helpful in getting to the bottom of this. Thank you! I tried to create a sample for you. And during this process I significantly narrowed down on the issue! To me it looks like if you add a handler to the WebMessageReceived event inside of a ListView ItemTemplate. That prevents it from being disposed. <ListView SelectionMode="None" ItemsSource="{x:Bind AllTheWebsites, Mode=OneWay}">
<ListView.ItemTemplate>
<DataTemplate x:DataType="local:WebSiteVM">
<WebView2 Height="500" WebMessageReceived="MyWebView_WebMessageReceived" Name="MyWebView" Source="{x:Bind TheUri}" />
</DataTemplate>
</ListView.ItemTemplate>
<ListView.ItemContainerStyle>
<Style TargetType="ListViewItem">
<Setter Property="HorizontalContentAlignment" Value="Stretch" />
</Style>
</ListView.ItemContainerStyle>
</ListView> See complete sample here. |
Switching from a ListView to an ItemsControl has completely solved this issue for me. Should I update the issue description and title? Or should I file a seperate issue? |
@Marv51 thank you for the additional investigation! I recently became aware of a a known issue causing leaks on navigation in C#/winrt apps - microsoft/CsWinRT#413. I wonder if that could be what we're seeing here? That problem was recently fixed with microsoft/CsWinRT#782, available in servicing update Reunion 0.5.5. Can you check if you are using 0.5.5? There is info on upgrading here. |
I am using 0.5.5 now. For me this issue has been narrowed down to the ListView control. The disposing of WebView 2 works for me now under most circumstances, very possible that 0.5.5 fixed this. I am not sure if 0.5.5 was already out when I first filed this issue. Something about the usage inside a DataTemplate for a ListView does keep the WebView from being disposed correctly. Especially if you hook up events, like the Could these be two separate issues? of course. |
I'll close this for now as the main issue was solved. |
Describe the bug
WebView2 is never unloaded and resources are consumed for the life time of the WinUI 3 app.
My app has an in-app help browser that shows our help website.
Steps to reproduce the bug
We have a page in WinUI 3 that hosts a Frame which hosts a Page with a WebView2 control.
The Frame gets removed from the tree which makes it not visible anymore
Running "tabs" can be checked by opening the Inspector and right clicking on the title bar and selecting "Browser Task Manager" (Windows Task Manager seems to corroborate this interpretation)
Visual Tree looks like this:
Window
Frame
Page
Frame <-- gets added and removed
Page
WebView2
Expected behavior
After the Control is removed from the visual tree, the tab should be closed. After not showing any WebView2 controls for a while all WebView2 processes should exit.
Version Info
NuGet package version:
WinUI 3 - Project Reunion 0.5: 0.5.0
Windows app type:
Additional context
I could not find any documentation on how to dispose a WebView2. The c# samples do not seem to cover this scenario.
The text was updated successfully, but these errors were encountered: