bug: NavigationViewItemAutomationPeer causes UI thread freeze / crash on Wine and degraded Windows UIA environments

Describe the bug

Under specific runtime environments—most notably Wine/Proton on Linux as well as Windows 10/11 machines with corrupted UIAutomationCore providers or active accessibility/overlay hooks—interactions involving NavigationViewItem can cause a complete UI thread deadlock or application freeze/crash.

The issue occurs when WPF queries NavigationViewItem.OnCreateAutomationPeer(). If the underlying system's COM/UIAutomationCore bridge fails or throws an exception during NavigationViewItemAutomationPeer instantiation, the exception escapes into WPF's ContextLayoutManager or Dispatcher frame, freezing the application (especially during menu expansion or modal dialog transitions).

To Reproduce

1. Run a WPF application utilizing Wpf.Ui (NavigationViewItem).
2. Interact with a NavigationViewItem (e.g., expand child items or trigger a modal dialog / context menu transition).
3. Observe the result:

• Linux (Wine/Proton): The application typically crashes to desktop.
• Windows 10/11 (with hooked/degraded UIA providers): Unable to full reproduce this, but appears as though its an unobserved exception, but continues to work fine

Expected behavior

If NavigationViewItemAutomationPeer fails to instantiate due to environment/COM interface limitations, OnCreateAutomationPeer() should catch the exception and fall back gracefully to a standard FrameworkElementAutomationPeer. This prevents process crashes on Linux while allowing layout passes to complete normally on Windows.

Screenshots

No response

OS version

Windows 10, Linux (Wine / SteamOS / Proton)

.NET version

.NET Framework 4.8.1

WPF-UI NuGet version

4.2.1, 4.3.0

Can be traced to #1646

Additional context

Stack Trace

System.MissingMethodException: Method not found: 'System.Windows.Automation.Provider.IRawElementProviderSimple System.Windows.Automation.Provider.ISelectionItemProvider.get_SelectionContainer()'.
   at Wpf.Ui.Controls.NavigationViewItem.OnCreateAutomationPeer()
   at System.Windows.UIElement.CreateAutomationPeer()
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.iterate(DependencyObject parent, IteratorCallback callback)
   at System.Windows.Automation.Peers.UIElementAutomationPeer.GetChildrenCore()
   at System.Windows.Automation.Peers.AutomationPeer.EnsureChildren()
   at System.Windows.Automation.Peers.AutomationPeer.UpdateChildrenInternal(Int32 invalidateLimit)
   at System.Windows.Automation.Peers.AutomationPeer.UpdateChildren()
   at System.Windows.Automation.Peers.AutomationPeer.UpdateSubtree()
   at System.Windows.ContextLayoutManager.fireAutomationEvents()
   at System.Windows.ContextLayoutManager.UpdateLayout()
   at System.Windows.Controls.VirtualizingStackPanel.<>c__DisplayClass94_0.<InitializeViewport>b__0()
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

I've had this tested and can reproduce on a Linux system (wine) without fail. I have Sentry logs for Windows 10 (2022H), but unable to reproduce this scenario, but stack trace is identical.

Proposed Fix

Add defensive try/catch exception handling around NavigationViewItemAutomationPeer creation in NavigationViewItem.cs:

protected override AutomationPeer OnCreateAutomationPeer()
{
    try
    {
        return new NavigationViewItemAutomationPeer(this);
    }
    catch
    {
        // Fall back gracefully if UIAutomationCore or COM interface queries fail 
        // (e.g., Wine/Proton environments or broken Windows UIA drivers)
        return new FrameworkElementAutomationPeer(this);
    }
}

Start in NavigationViewItem.cs at OnCreateAutomationPeer() and compare the supplied stack trace with the NavigationViewItemAutomationPeer construction path. Validate the behavior in the reported Wine/Proton environment and confirm that UIAutomation failures no longer crash or freeze layout, while the normal peer behavior remains intact.