Closing Popup on back button with android:enableOnBackInvokedCallback="true"

[JamesBrooksbankIceland]

Description

We discovered an issue with our sfpopup where the back button wasn't working when it was opened. It closed when the user tapped outside of the popup but not on the back button.

So after creating a new app and replicating our code, we noticed that the back button was working. However, the production app wasn't. After a bit I discovered that the backbutton wasn't working on the popup because of android:enableOnBackInvokedCallback="true"

When true, then the back button does not close when the popup menu is open.

Steps to Reproduce

1. Create new maui project
2. In page add a popup and button which shows
3. Make sure in the android manifest this is set android:enableOnBackInvokedCallback="true"
4. Open the popup
5. Try closing by pressing the back button and it's not working

Problem is with version 1.0.9

My sample project is here in github
https://github.com/[JamesBrooksbankIceland/PopupmenuSample](https://github.com/JamesBrooksbankIceland/PopupmenuSample)

.NET Version

.NET 10.0

Version with bug

1.0.7

Is this a regression from previous behavior?

No, this is a new issue

Last Known Working Version

1.0.6

Affected platforms

Android

Affected Platform Versions

Android 14 at least

Have you found a workaround?

No response

Relevant log output

[AmalRajUmapathySelvam]

@JamesBrooksbankIceland - This issue occurs due to changes in Android’s back‑navigation handling in newer versions.
Our PopupMenu currently relies on the legacy OnBackPressedCallback mechanism. On Android 13 (API 33), this still works because the system provides backward compatibility even when android:enableOnBackInvokedCallback="true" is enabled.
However, starting from Android 14 (API 34+), the legacy back‑press handling is completely bypassed, and only the new OnBackInvokedCallback API is honored. Since our control does not yet register with this new callback system, the back button event is never received, causing the PopupMenu to remain open.

Our team is currently working on fixing this issue. The fix will be included in our upcoming .NET MAUI Toolkit release, which is expected to be scheduled for mid‑May 2026. We will keep you informed once the fix is available.

[JamesBrooksbankIceland]

Yeah we had a similar issue when we upgraded our app to the new platform so I thought this was the case. Thanks for the update. Looking forward to the May release.

[AmalRajUmapathySelvam]

@JamesBrooksbankIceland - We reviewed this across Android versions and want to clarify what’s happening and our recommendation.

In Android 14, when the manifest flag android:enableOnBackInvokedCallback="true" is enabled, the platform enforces Predictive Back navigation and delivers back events only to system‑recognized back targets. As a result, with Predictive Back enabled the popup does not receive the back action on Android 14 and 15 and therefore does not close. This is a platform‑level change and is not caused by application logic. Android 13 allowed fallback behavior (which is why the popup closed there). In Android 16 Predictive Back handling is further stabilized and the behavior becomes consistent again.

If Predictive Back is disabled (android:enableOnBackInvokedCallback="false"), the standard back‑button navigation is used and the popup closes correctly across Android 13–16.

We recommend setting android:enableOnBackInvokedCallback="false" for Android 14 and 15 to ensure consistent popup back‑navigation behavior. Disabling this flag does not affect normal back navigation unless your application explicitly relies on predictive back gesture previews or animations.

If you must keep Predictive Back enabled, please share the reason or the specific behavior you expect . We will review and advise on possible workarounds given the platform limitations.

Predictive Back overview: https://developer.android.com/guide/navigation/predictive-back-gesture

Android 14 behavior changes: https://developer.android.com/about/versions/14/behavior-changes-14

Thanks again for raising this. If you share your manifest file or more context about how the popup is registered for back handling, we can provide targeted guidance.

[JamesBrooksbankIceland]

Hi thanks for your response. So we need the predictive behaviour as users have become used to it. We can't go to platform 16 as this is the devices the application are going on is locked down to 14.

The github repository i posted is a toned down version of the implementation we use.

[AmalRajUmapathySelvam]

We understand that you still need the predictive behavior and can't update to recent platform. We are currently working with basic demo of our own with your predictive back approach, and we couldn't access your shared GitHub repo. It would be better if you can share the GitHub repo with sharing access for us.

Additionally, please let us know whether the ShowOverlayAlways property is set to true or false in your scenario. This information will help us analyze the issue further and identify an appropriate alternate solution at the earliest.

[JamesBrooksbankIceland]

Could you try this

https://github.com/JamesBrooksbankIceland/PopupmenuSample

Hopefully that will work.

ShowOverlay is not set so it's the default.

[AmalRajUmapathySelvam]

@JamesBrooksbankIceland - Thank you for your update.

The ShowOverlayAlways property is enabled by default. Currently, the Popup is not added to the root view. We have explored an alternative approach where the Popup is added to the root view when the overlay is disabled. With this approach, the framework’s back button navigation notifications are received correctly.

Could you please confirm whether the overlay is mandatory for your scenario, or if it can be disabled? This will help us proceed with the most appropriate solution.