Android NavigationPage in inconsistent state if Push/Pop operations are performed sometime after app deactivation

[Nibby]

Description

On Android, the NavigationPage will sometimes fail completely if the app schedules a PushAsync() or PopAsync() action sometime after the app has been backgrounded (i.e. Deactivated and Stopped lifecycle event received from the Window).

In the case of a scheduled PopAsync(), the awaited line sometimes never complete:

Page poppedPage = await Navigation.PopAsync();

If the PopAsync() task does not complete successfully, the following log message can be observed in LogCat:

I/FragmentNavigator(11593): Ignoring popBackStack() call: FragmentManager has already saved its state

I am not familiar with Android internals. From what I understand, when the app is backgrounded, the Android system (probably) calls Activity.onSaveInstanceState() at some point, which also calls the same method for all its child fragments. This prevented MAUI's StackNavigationManager from successfully calling Navigate() and PopBackState()... which then means the NavigationFinished in that class is never called to complete the awaited task.

Ultimately, the app's scheduled background push/pop task is in a race against Android's state save calls. In my sample project, you can modify the task delay in App.xaml:26 to verify this. The shorter the delay, the operation will sometimes succeed. If the delay is longer than 5 seconds, the operation almost always fails.

I consider this a bug as the behaviour is not consistent with iOS.

On iOS, when the app is backgrounded, the delayed PopAsync() call is not executed until next time the user resumes the app. Eventually the user will observe the correct screen. Same goes for PushAsync().

Steps to Reproduce

Example PopAsync() Scenario

1. The app has two pages in its navigation stack [A, B] where B is the displayed top-most page.
2. The app is programmed to POP the top-most page after it receives the Deactivated lifecycle event.
3. User presses the home button and the app is put into background.
4. Very shortly after, user resumes the app.

Expected
By the time the app is resumed into foreground, user should observe page A

Observed
The user sometimes observe page A, other times observes a white screen instead.

Example PushAsync() Scenario

1. The app has two pages in its navigation stack [A, B] where B is the displayed top-most page.
2. The app is programmed to PUSH another page, C, some 2 seconds after it receives the Deactivated lifecycle event.
3. User presses the home button and the app is put into background.
4. Very shortly after, user resumes the app.

Expected
By the time the app is resumed into foreground, user should observe page C

Observed
The user sometimes observe page C, other times observes the original page B. Attempting to pop page B using the UI back button causes the navigation page to show a white view.

Link to public reproduction project repository

https://github.com/Nibby/MAUI-Bug-2

Version with bug

7.0.86

Last version that worked well

Unknown/Other

Affected platforms

Android, I was not able test on other platforms

Affected platform versions

Tested Android API versions 28 and up, and they all exhibited this issue

Did you find any workaround?

The workaround is queue any page transitions requested after an app deactivate / stopped event is received, and execute them after the app is known to be resumed again.

Relevant log output

No response

[Nibby]

@PureWeen Perhaps you'd be the best person to look at this issue :)

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[XamlTest]

Verified this on Visual Studio Enterprise 17.8.0 Preview 1.0. Repro on Android 13.0-API33 .NET 8, not repro on Windows 11 and iOS 16.4 with below Project:
16441.zip

[MGohil]

@PureWeen @jsuarezruiz

We have API calls on page, and when api success we navigate to other page, but meanwhile if user moves app to background, the navigation doesn't perform and result into an error. This is causing issues in android app.

We can't ask our end users to stay on app (Keep app Active) until data processed and navigation completes. This is bad user experience.

It would be great if Maui team recognise the priority of this issue and fix this ASAP.

Thanks.

[YZahringer]

Similar issue on Windows #18982

[BurkusCat]

I believe this issue is the same as #21113 and for me, it is fixed when trying out the nightly: https://github.com/dotnet/maui/wiki/Nightly-Builds