NavigationView leads to internal crash when close pane by hamburger menu

[SeRgI1982]

Describe the bug

The bug happens randomly, so hard to tell what is the issue.
Callstack says that it happens when NavigationView goes to state, so I am guessing that the issue is with animation.
I have raised similar bug a couple of months ago:
#8240

Steps to reproduce the bug

1. Open & Close NavigationView Pane by hamburger menu

Expected behavior

Open & Close NavigationView Pane works always and even if some internal exception happens (for ex. because of a buggy animation), the control will not crash but jumps to the final state of this animation.

Screenshots

NuGet package version

WinUI 3 - Windows App SDK 1.4.4: 1.4.231219000

Windows version

Windows 11 (22H2): Build 22621

Additional context

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Open similar issues:

• NavigationView leads to internal crash when close the application (#8240), similarity score: 0.83

Closed similar issues:

• NavigationView Pane does not close after clicking on an item (#2244), similarity score: 0.76
• NavigationView crashes when full screen (#6788), similarity score: 0.71
• NavigationView with MenuItemTemplateSelector crashes (#4511), similarity score: 0.71
• NavigationView PaneTitle bug on open (#4122), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[TPopiel]

Seems that issue is easily to reproduce with WinUI3 Gallery app.

Here are the steps:

1. Go to "Navigation\NavigationView"
2. Select "Menu Item3"
3. Go to "Motivation\Connected Animation"
4. Go to "Navigation\NavigationView"

Observed behavior: crash of the app (if not repeat steps 2 -4)

[JJBrychell]

This issue has been addressed and is scheduled for the next preview release of 1.6.

Problem arises from managed garbage collection interaction with the internal radio button tables. When a radio button is named it is entered into an internal table that is searched when determining which button(s) to uncheck when a new button is checked. The entry stays in this table until the radio button is destructed, but with garbage collection it can stick around for a while after it been removed from the tree. So when you show/hide the pane, you can get multiple sets of radio buttons for the pane in this internal table. This is handled correctly, except when the timing of garbage collection is just right. When garbage collection happens, it does so off the UI thread, so it only partially destructs the UI element and then schedules the rest of it to be done on the UI thread. If a check box checked changes comes in between when garbage collection has partially destructed the item, but the UI thread hasn't completed that destruction, the radio button code doesn't realize that even though it still exists, it is in a bad state that ultimately causes this crash. We have modified the process to no longer rely on any of the data that is partially destructed in garbage collection.