WebView2 leaks old msedgewebview2.exe processes with every page change

[sude22]

Describe the bug

A WinUI3 app with shell navigation. Several pages use the WebView2 control.
A new instance of "msedgewebview2.exe" is created every time the page is changed, even the GC never clears it.

Steps to reproduce the bug

Change between the pages

Expected behavior

The old instances should be cleared

Screenshots

NuGet package version

WinUI 3 - Windows App SDK 1.4.2: 1.4.231008000

Windows version

Windows 10 (21H2): Build 19044

Additional context

No response

[codendone]

Changed title to indicate the issue is leaking the old processes.

[sude22]

OK,
Unfortunately, I don't know the internal processes in Shell Navigation. But certainly every time switching to a new page, it is recreated, but the old instances are not cleaned up. The workaround for us now (since we don't need a back and forth function) is not to call the Frame.Navigate() method, but to create the pages ourselves, cache them, and assign them to the Frame.Content if necessary.

[codendone]

Calling Close() on WebView2 instances before navigating away from the page should also force process cleanup.

[ranjeshj]

@sude22 I'm not sure who is caching the element. Are you able to repro this with WinUI 3 gallery? Can you share a repro?

[HO-COOH]

@sude22 I'm not sure who is caching the element. Are you able to repro this with WinUI 3 gallery? Can you share a repro?

@ranjeshj The issue seems to be reproducible with WinUI3 gallery. You just go to webview2 page, open a console, switch to other pages then switch back and open another console. Do this for multiple times, and you can see all the console windows' are not closed

[huwaireb]

👋 This issue is still reproducible in latest versions of WinUI 3 Gallery,

Screen.Recording.2024-07-07.at.17.26.39.mov

The two cents of someone new to WinUI

WinUI's management of the lifecycle of the control shouldn't end when instantiating the <WebView2 ../> control, however it should also account for it's disposal. It shouldn't try to instantiate a new instance if one already exists.

Manually disposing should only be done if needed for ui logic.

There should be means of "persisting" the instance in order to retain state, but by default dispose of its self. Then it would be expected behavior as how it's treated in the documentation, examples and WinUI 3 gallery.

P.S: Please stop closing issues that are clear bugs just because the OP doesn't respond. In this case a third party provided instructions to reproduce yet it closed anyhow, but even the OP's explanation was clear enough.