Xamarin.forms: [Bug] Navigation outside the shell hirerchy does not return back to the root

Created on 11 Jul 2019  路  9Comments  路  Source: xamarin/Xamarin.Forms

Description

I defined first page as content of tab bar. The second page is not part of the shell. Now I want to navigate between these two pages on user interaction ( button click). when I come back to first page from second page I expect to navigate be the root page and have hamburger menu. But the first page have back button and it does not have hamburger menu.

Basic Information

Reproduction Link

ShellData.zip

backbutton shell 4 bug

Most helpful comment

@PureWeen OK I'm sorry I tried to be as clear as possible

I've done a video which I hope will demonstrate the situation better

https://youtu.be/Hl9llch8sBA

in that sample I can only ever click one monkey

Sorry, I've tried to demonstrate what I said in the video - you select a number of different monkeys from the list and by doing so build up a history array by incrementing the NavigationStack count. That is the issue that's causing the problem - that when you navigate away from then return to the Monkeys list, you have to go back through all the pages you visited. The workaround suggested, if I followed it correctly, said to look for an increase in NavigationStack and pop to root, but as I've shown in the video, the size of the stack is shown as 1 even when there are pages to go back through. Hope the video makes that clear?

Not sure what you're referring to here

If you look at the XAML in the example, the animals (Cat, Dog, Bear etc) are ShellContent items contained within a FlyoutItem, so a group. The issue with the history array doesn't occur if you navigate only within that group. The About ShellContent item is outside the group, I don't know why that's a factor but again hopefully the video illustrates the problem and provides a reliable reproduction case

All 9 comments

Verified. At first I thought this was happening: whenever navigating the stack would just get the new page on top and that is why you would always have the back arrow. But that is not the case. The navigation stack does not grow [0] is always null and [1] is always the current page in Shell.Current.Navigation.NavigationStack. Therefore, I would expect that the hamburger icon is _always_ visible, instead the back button is.

Unless I am missing something here @PureWeen ?

There are several possible workarounds for this, the easiest one would be to replace the call on the second page with Shell.Current.SendBackButtonPressed();

In latest Xamarin.Forms 4.4.0.991640 the Shell not even allow to go back to firstpage. Although the suggestion by @jfversluis to use Shell.Current.SendBackButtonPressed(); is working fine. This is a blocker for Shell use as someone may need to bring in some data to first root page using GotoAsync();

@PureWeen @samhouts @jfversluis I didn't feel this like a low priority. I am unable to use shell due to this bug. Shell.Current.SendBackButtonPressed(); doesn't always helpful. As the user may have navigated from another page and want to go to root page. Please suggest some workaround.

Yea this one was a bit of an oversight when putting together the Uri navigation

With shell
```C#
Shell.Current.GoToAsync("//first");

Just switches you to a a different item but it doesn't pop anything off the stack which is confusing based on how other URI navigation inside shell works

That being said when you're navigating between tabs you don't always want to return to root. Like when clicking between tabs or flyout items you don't always want the stack to pop down to the bottom

So we need to figure out a way to express both.

1) I want to switch to "//first" but don't pop the stack
2) I want to switch to "//first" and have that be the root element

not sure off hand :-/ 

This is a variation you could do to change the behavior when you're on that secondpage
```C#
            if (Navigation.NavigationStack.Count > 1)
                Navigation.PopAsync();
            else
                Shell.Current.GoToAsync("//first");

You could create two versions of secondpage that inherit from a base class.

You could create a viewmodel where you pass a parameter to it indicating if the page is part of shell or it's pushed on

You could also inspect Shell.Current.CurrentState to figure out if you should pop or not

The GotoAsync API definitely needs to be improved here

from @DaveBrickley

hi, thanks for confirming, I hadn't seen this issue. Is the example in the one you link to a valid workaround? As I can't see how you'd apply it in my case, both my pages are shell pages, and I cannot see any way to override the default behaviour of a Flyout menu click since there doesn't appear to be any way of trapping the click? Hmm, one thought does occur, can you set a view model to be binding context for appshell and then use a command in the flyout entry references that would pass the context to the related commant method for ontapped?

I would need to test but I think the way to achieve your behavior would be to wire into the Navigated event. When you see a user navigate to a new flyout item then call "Navigation.PoptoRoot"

@PureWeen @samhouts

Using the Xaminals Github project, I have been able to demonstrate that Navigation.PopToRoot is not a suitable workaround for the simple reason that the NavigationStack incorrectly shows as 1 even though the app itself is showing you a series of pages that you have to click back through. The code itself only needs a simple modification in the Navigating method to demonstrate this:

In the Xaminals code project (available here) https://github.com/xamarin/xamarin-forms-samples/tree/master/UserInterface/Xaminals/Xaminals

  • The author has put four items inside FlyoutItem and three outside
  • Select monkeys. Click four or five monkeys, just to build up the Navigation stack (you can see this incrementing in debug if you add a statement to that effect)
  • Now click About (which is just a ShellContent item outside the Flyout)
  • Now click Monkeys again. Instead of seeing the Index page of monkeys, you have to browse back through the four or five you picked before you get to the index page again
  • HOWEVER, on selecting Monkeys the second time, having been to About, NavigationsStack count in debug is 1, meaning you cannot simply do a PopToRoot to look for this outcome
  • This behaviour does NOT occur if every item is inside FlyoutItem, but I need to have more than five menu options, so it's unavoidable, since FlyoutItem has apparently got a hard limit of five

@DaveBrickley sorry but I'm not following your train of thought here.

Click four or five monkeys, just to build up the Navigation stack (you can see this incrementing in debug if you add a statement to that effect)

in that sample I can only ever click one monkey

This behaviour does NOT occur if every item is inside FlyoutItem, but I need to have more than five menu options, so it's unavoidable, since FlyoutItem has apparently got a hard limit of five

Not sure what you're referring to here

@PureWeen OK I'm sorry I tried to be as clear as possible

I've done a video which I hope will demonstrate the situation better

https://youtu.be/Hl9llch8sBA

in that sample I can only ever click one monkey

Sorry, I've tried to demonstrate what I said in the video - you select a number of different monkeys from the list and by doing so build up a history array by incrementing the NavigationStack count. That is the issue that's causing the problem - that when you navigate away from then return to the Monkeys list, you have to go back through all the pages you visited. The workaround suggested, if I followed it correctly, said to look for an increase in NavigationStack and pop to root, but as I've shown in the video, the size of the stack is shown as 1 even when there are pages to go back through. Hope the video makes that clear?

Not sure what you're referring to here

If you look at the XAML in the example, the animals (Cat, Dog, Bear etc) are ShellContent items contained within a FlyoutItem, so a group. The issue with the history array doesn't occur if you navigate only within that group. The About ShellContent item is outside the group, I don't know why that's a factor but again hopefully the video illustrates the problem and provides a reliable reproduction case

Was this page helpful?
0 / 5 - 0 ratings