[BUG] Router.NavigateBack seems to be broken in some cases

[andrejpanjan]

Describe the bug
It look likes that Router.NavigateBack doesn't work as expected in some cases on Xamarin Forms, while the same code works perfectly on WPF.

Steps To Reproduce

Use attached Test.
Test.zip

1. Tap Check Out on the Main Page.
2. Tap Save on the CheckOut page.
3. Tap Save on the Production page.
4. It should return to Main Page, but it doesn't. Also Router.NavigationStack and NavigationPage.Navigation.NavigationStack are not synchronized anymore.

Expected behavior
It should return to the Main Page when Save is tapped on the Production page.

Environment

• OS: Android, Xamarin Forms
• Version: 10
• Device: Pixel 2

Additional context
May be related to #2040

[open-collective-bot]

Hey @andrejpanjan 👋,

Thank you for contributing to our project financially. We will handle your issue with priority support. To make sure we don't forget how special you are, we added a priority label to your issue.

Thank you again for contributing 🎉!

[glennawatson]

I'll take a look at this one in the new year.

[andrejpanjan]

Is this planned to be fixed soon? Otherwise, I will start looking for a workaround.

[RLittlesII]

@andrejpanjan We have been working on clearing bugs recently. I was able to reproduce #2040, I can push this further up my queue, can't commit to a "soon" timeline for resolution.

[glennawatson]

This issue is the one we are looking into now btw.

[RLittlesII]

@andrejpanjan I was looking at this last night. This is what I see.

• The RoutedViewHost for XF seems to be popping to root on the first NavigateBack (Step 2)
• The second NavigateBack never reaches the call to the INavigation (Step 3)
  • This results in the NavigationStack getting out of sink
  • I watch the NavigateBack execute, but it seems the NavigationChanged observable doesn't tick

[andrejpanjan]

@RLittlesII I think that your are mostly correct, expect that based on my observation the NavigationChanged observable does tick on the second NavigateBack.

I've put a couple of debug outputs in the attached Test.zip to track both NavigationStack-s. You can find them in the AppBootstrapper.cs. ADD and REMOVE lines are related to the Router.NavigationStack and PUSH and POP lines are related to the Navigation.NavigationStack. COUNT is a current NavigationStack count.

Here is what I see:

1. Tap Check Out on the Main Page.
   ADD: CheckOut COUNT: 2 TIME: 1/10/2020 6:58:09 PM
   PUSH: CheckOut COUNT: 2 TIME: 1/10/2020 6:58:10 PM

2. Tap Save on the CheckOut page.
   REMOVE: CheckOut COUNT: 1 TIME: 1/10/2020 6:58:14 PM
   ADD: Production COUNT: 2 TIME: 1/10/2020 6:58:14 PM
   PUSH: Production COUNT: 2 TIME: 1/10/2020 6:58:14 PM

3. Tap Save on the Production page.
   REMOVE: Production COUNT: 1 TIME: 1/10/2020 6:58:18 PM

4. Tap on the Back button
   POP: Production COUNT: 1 TIME: 1/10/2020 6:59:47 PM
   REMOVE: Main Page COUNT: 0 TIME: 1/10/2020 6:59:47 PM

REMOVE in step 3 is a result of the Router.NavigationChanged.
I'm not sure why there is no POP action in step 2 and step 3, but based on the COUNT it actually occurred.

[RLittlesII]

@andrejpanjan Yes. I saw that. I am using your sample to debug the problem. Digging into the framework I am looking at when the actual NavigationPage fires NavigationEventArgs for the Popped event handler.

XF actually makes a distinction (although not clear) between Popped and PoppedToRoot. The code you have written never seems to hit the PopAsync on the RoutedViewHost. That said, I don't believe it's your code that's causing this behavior.

We also make a distinction listening for the Popped based on whether it is a custom command or the software back button. I am still digging. Just wanted to give you an update an corroborate.

[glennawatson]

It seems @RLittlesII may have to refactor two classes to take the view model pushes from the xam forms events.

[RLittlesII]

@glennawatson I think that is the cleanest way. I am still investigating a less invasive approach. It just doesn't seem to make sense that the second tick of Router.NavigationChanged doesn't effect a corresponding PopAsync.

@andrejpanjan After rereading your points, and looking at this again.
The POP isn't called because it isn't firing the INavigation.PopAsync. It is firing INavigation.PopToRootAsync. This emits a different event, so the RoutedViewHost doesn't see the NavigationEventArgs for the Popped event handler to call the PopAsync.

PopAsync only seems to respect the software back button (the button provided by the navigation page).