[BUG] [iOS] CommunityToolkit.Maui Popup crashes with PopupNotFoundException on CloseAsync

[MatthewJer]

Is there an existing issue for this?

• I have searched the existing issues

Did you read the "Reporting a bug" section on Contributing file?

• I have read the "Reporting a bug" section on Contributing file: https://github.com/CommunityToolkit/Maui/blob/main/CONTRIBUTING.md#reporting-a-bug

Current Behavior

When repeatedly opening and closing a CommunityToolkit.Maui.Views.Popup on iOS, the following exception is eventually thrown:

CommunityToolkit.Maui.Views.PopupNotFoundException
Unable to close popup: could not locate PopupPage.

I suspect this happens because CloseAsync() can be triggered multiple times for the same popup instance, causing the internal popup state to become invalid.

Observed behavior:

Popup opens/closes normally at first
After repeated open/close cycles the exception is thrown
In some cases the app terminates afterwards on iOS

Expected Behavior

Calling CloseAsync() multiple times should either be ignored safely or handled gracefully without throwing PopupNotFoundException.

Steps To Reproduce

1. Clone and run the reproduction repository on iOS (preferably on a physical device).

2. Open the popup using the button on the main page.

3. Close the popup using the button inside the popup.

Additional notes:

• The issue is easier to reproduce on a physical iPhone.
• Rapidly tapping both buttons with two fingers seems to increase the likelihood significantly.
• Rapid double tapping outside the popup backdrop may potentially be the actual trigger, but this could not be confirmed yet.
• The exception usually appears after a few minutes of repeated interaction.

Link to public reproduction project repository

https://github.com/MatthewJer/TestPopup

Environment

* .NET MAUI CommunityToolkit: 14.1.1
* OS: iOS (physical device)
* .NET MAUI: 10.0.60
* Xcode: 26.4
* Reproduced on: iPhone

Anything else?

A potentially related issue was previously reported here:

• [CommunityToolkit/Maui Issue #2738](https://github.com/CommunityToolkit/Maui/issues/2738?utm_source=chatgpt.com)

However, that report contains less detail and I could not find other issues clearly matching this behavior.

Since I now have:

• a minimal reproduction repository
• a fairly reliable reproduction path
• and additional observations regarding rapid repeated interactions

I decided to open a dedicated issue.

At the moment, this is currently our number one crash cause on iOS.

Any suggested workarounds or mitigation strategies would be highly appreciated while waiting for a proper fix.

Observed stacktrace:

Unable to close popup: could not locate PopupPage. ShowPopup or ShowPopupAsync must be called before CloseAsync. If using a custom implementation of Popup, override the CloseAsync method
at CommunityToolkit.Maui.Views.PopupPage.CloseAsync(PopupResult result, CancellationToken token) in /_/src/CommunityToolkit.Maui/Views/Popup/PopupPage.shared.cs:line 86
at MauiApp1.MyPopup.Button_Clicked(Object sender, EventArgs e) in /Volumes/SDCard/WorkSpace/PopupTest/Popups/MyPopup.xaml.cs:line 14
at System.Threading.Tasks.Task.<>c.b__124_0(Object state)
at Foundation.NSAsyncSynchronizationContextDispatcher.Apply()

[bijington]

I suspect it happens in your example because you are using an async void therefore multiple button presses are possible. If you look to protect the button click method from being re-entered until the popup has closed that would avoid this issue. Alternatively look into RelayCommamd from the MVVM toolkit that can manage this for you

[MatthewJer]

I tried guarding the button handler against reentrancy already, for example:

public partial class MyPopup : Popup
{
    private SemaphoreSlim semaphore = new SemaphoreSlim(1,1);

    private async void Button_Clicked(object sender, EventArgs e)
    {
        if (!await semaphore.WaitAsync(0))
            return;

        try
        {
            await CloseAsync();
        }
        finally
        {
            semaphore.Release();
        }
    }
}

However, the issue still occurs reliably after repeated interactions.

The semaphore should prevent multiple concurrent executions originating from the button handler itself, which makes me suspect that CloseAsync() may additionally be triggered internally (for example through tapping outside the popup backdrop) while another close operation is already in progress.

I already tried several mitigation approaches in our production code, but none of them seem to reliably guarantee that the issue cannot occur anymore.

Because of this, I think the toolkit itself should probably defensively handle multiple CloseAsync() calls for the same popup instance and ignore subsequent calls once the popup is already closing/closed.

[MatthewJer]

After being back in the office today, I was able to gather more information about this issue.

It does not actually seem to be a PopupNotFoundException when I can reliably reproduce the problem.
The call stack looks like this instead:

Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
    at System.Collections.Generic.List`1[[Microsoft.Maui.Controls.NavigationStepRequest, Microsoft.Maui.Controls, Version=10.0.0.0, Culture=neutral, PublicKeyToken=null]].get_Item(Int32 index)
    at Microsoft.Maui.Controls.NavigatingStepRequestList.get_Item(Int32 index)
    at Microsoft.Maui.Controls.Platform.ModalNavigationManager.PopModalAsync(Boolean animated)
    at CommunityToolkit.Maui.Views.PopupPage.CloseAsync(PopupResult result, CancellationToken token) in /_/src/CommunityToolkit.Maui/Views/Popup/PopupPage.shared.cs:line 119
    at CommunityToolkit.Maui.Views.PopupPage.<>c__DisplayClass4_0.<<-ctor>b__0>d.MoveNext() in /_/src/CommunityToolkit.Maui/Views/Popup/PopupPage.shared.cs:line 46
    at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__124_0(Object state)
    at Foundation.NSAsyncSynchronizationContextDispatcher.Apply() in /Users/builder/azdo/_work/2/s/macios/src/Foundation/NSAction.cs:line 165
    at Foundation.NSAsyncSynchronizationContextDispatcher.__Registrar_Callbacks__.callback_3798_Foundation_NSAsyncSynchronizationContextDispatcher_Apply(IntPtr pobj, IntPtr sel, IntPtr* exception_gchandle)

The issue can currently only be reproduced in our production code when the popup is dismissed by tapping outside of the popup.

If I understand the implementation correctly, the handler in PopupPage.shared.cs that handles dismissing the popup is also implemented as async void. That would mean multiple invocations are potentially possible there as well, which could explain the inconsistent modal navigation state and the resulting IndexOutOfRangeException.