[BUG] PopupV2 – Incorrect behavior when opened from a modal page wrapped in a NavigationPage

[vecalion]

Current Behavior

When a popup is opened from a modal page wrapped in a NavigationPage, the background turns grey and _popupService.ClosePopupAsync(Shell.Current) stops working. See the screen recording:

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2025-11-18.at.11.27.49.mov

Expected Behavior

The popup’s behavior shouldn’t differ from opening it from any other page or from a modal that isn’t wrapped in a NavigationPage. In other words, the background should behave normally, and _popupService.ClosePopupAsync(Shell.Current) should work without issues.

Steps To Reproduce

1. Open and run the repro project
2. Tap on the second button - Open Modal (NavigationPage) - BUG
3. Tap on the 'Open Popup' button

Link to public reproduction project repository

https://github.com/vecalion/PopupBugRepro

Environment

- .NET MAUI CommunityToolkit: 13.0.0
- OS: iOS
- .NET MAUI: 10.0.10

[skha83]

The part about the background turning grey, when the dialog opens, might be a core MAUI library issue, and not a specific CommunityToolkit.MAUI Popup issue. I see the exact same behavior using another package for popup/dialog handling https://github.com/PrismLibrary/Prism.
My page launching the dialog is also wrapped in a NavigationPage and the background page also turns grey when the popup is opened. I'm also running .NET MAUI: 10.0.10 and I see the problem on both iOS and Android.
I don't have any problems closing my dialogs, so that part might be specific to the CommunityToolkit.MAUI Popups implementation.

[skha83]

Regarding your problem with not being able to close the popup. A long shot could be that your problem is related to this issue dotnet/maui#32586 where some UI calculations are causing the UI thread to never return, because they go into an infinite loop in some iOS safe area calculations. I had problems opening popups only on iOS, if I forced my open command to block the UI thread until the dialog was shown. This was only a problem on iOS, Android could show the dialog without problems, using the same blocking command. This had worked without problems on iOS before upgrading to .NET 10. It could be something similar in your case. If showing the popup also use some kind of animation or another thing which trigger the safe area calculation, then the call might never complete, due to the safe area calculations never returning. Even though the popup is visually shown, behind the scenes the UI thread is still blocked by these calculations and this will then block the close command from accepting input, because the open popup call never returned internally.

I know this is a long short, but if this PR dotnet/maui#32797 is fixed for MAUI SR2, then maybe this part will work again.

The grey background will most likely not be fixed by this, as this is a problem on both iOS and Android platforms.

[vecalion]

@skha83, did you find any workaround for the grey background issue in your project that uses prism?

[skha83]

Yeah. I discovered it was an error in my own code because I had the following style defined as a global app style:

<Style ApplyToDerivedTypes="True" TargetType="ContentPage">
   <Setter Property="Background">      
       <Setter.Value>
         <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
            <GradientStop Offset="0.0" Color="{StaticResource SetupStartGradient}"/>
               <GradientStop Offset="1.0" Color="{StaticResource SetupEndGradient}"/>
         </LinearGradientBrush>
       </Setter.Value>
   </Setter>
</Style>

All ContentPages and their derived types would get this background color, because of the ApplyToDerivedTypes attribute set to true. This had never been a problem with the old version of popups from CommunityToolkit, because this implementation didn't use the ContentPage class to show dialogs. But the switch to Prism, which use this class or a derived class for modal dialogs, caused my problem. I'm not sure which control type the new V2 of CommunityToolkit dialogs use to show modal dialogs, but you have to be careful not to override styles globally in this way. I had no idea this was done, as it was done before I was in charge of the project, so it took me some time to locate the problem.

[TheCodeTraveler]

Fixed in #2919