Memory leak while repeatedly navigating between pages

[Vroomer]

Description

Recurring navigation to a page and back causes memory leak. It can lead to extreme degradation in performance in a case of an app that uses TabbedPage with complex Views that contain a lot of controls.

In the app I'm developing I have a CollectionView of items which can be opened by user to show detailed information. The user has to be able to do such action hundreds of times during a session. However there seems to be something lingering in the memory which can't be collected by GC and isn't properly disposed.

I made a simple example consisting of two pages. The app is made so that you can easily push and pop a page. The pushed page consists only of a simple CollectionView.

• Tested on MAUI 7.0.0-rc.1.6683.
• The issue happens in Windows. I don't have the opportunity to test other platforms right now.
• The problem occurs with both Shell and standard page navigation.
• When there is no control on the pushed page, there is no leak.
• It doesn't seem to apply only to CollectionView.
• Instances of pages are kept in memory even after popping them. Triggering GC successfully collects them except for the last instance - not sure that is ideal.

Steps to Reproduce

1. Load the repository and run the app.
2. Repeatedly push and pop the page using the first button while observing memory usage in ResMon/memory profiler.
3. Click on the "Force GC" button to trigger GC - it will free some memory, but the memory leak should be apparent. You will also see text output from WeakReferences to pushed pages and their collections.

Link to public reproduction project repository

https://github.com/Vroomer/MAUI-navigation-memory-leak.git

Version with bug

Unknown/Other (please specify)

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

Windows SDK 10.0.22000

Did you find any workaround?

No response

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.

[jonathanpeppers]

At first thought, I thought this could be fixed by: #13833

But when I test the above sample, it leaks on Windows unless I make this change (<CollectionView x:Name="collectionView"):

private async void Button_Clicked(object sender, EventArgs e)
{
    await Navigation.PopAsync();
    // Fixes the leak?
    collectionView.Handler?.DisconnectHandler();
}

More investigation needed on this one, there must be another issue to solve.