PushModal on Windows does not show back button

[david-maw]

Description

Using Navigation.PushModalAsync inside a shell does not show a 'back' button on Windows (it does not need to on Android, which has a dedicated back button).

Steps to Reproduce

1. Unzip the project from
   MultiPage-windowsmodal.zip
2. Compile and run it on Windows, you should see this:
   
3. Click the PushAsync button, you should see this:
   
4. click the 'back' button (top left of page) to return to the main page then click the "PushModalAsync" button and you should see this:
   

There are several things to note:

1. There is no 'back' button
2. the child page navbar is invisible after PushModalAsync even though Shell.NavBarIsVisible="True" in the child page XAML.

Just in case it helped, I also tried:

NavigationPage.HasNavigationBar="True"
NavigationPage.HasBackButton="True"

It made no difference.

The lack of a 'back' button is a non-issue on Android which has its own dedicated back button. I'd also suggest that making the back button presence controllable with something like Shell.HasBackButton (or honoring Navigation.HasBackButton) would allow for a friendlier UI (though a back button which does nothing, controlled by Shell.BackButtonBehaviour seems arguably more like Android, for example).

Version with bug

Release Candidate 2 (current)

Last version that worked well

Unknown/Other

Affected platforms

Windows, I was not able test on other platforms

Affected platform versions

Windows 10

Did you find any workaround?

Using PushAsync instead of PushModalAsync is usually workable in the cases I've hit. but it has a problem that it also allows navigation to another shell child page (though not in this example, because there aren't any).

Relevant log output

No response

[PureWeen]

@david-maw the backbutton will only show up if you nest the modal inside a NavigationPage. Which I realize isn't the most intuitive thing but that's how it currently works. Is that your issue?

[david-maw]

@PureWeen I don't think so but I may be misunderstanding you. It's nested inside a Shell not a NavigationPage and PushAsync is showing a backbutton while PushModalAsync is not.

[PureWeen]

@david-maw Right, so a modal page is a space that's completely outside the space of the underlying pages. Think of it as a virtual windows. So the space inside the modal page is completely detached from a shell. So to have a back button you have to register a NavigationPage to your route and then push that.

[david-maw]

@PureWeen that's where I think I may be missing your point, when I replace the code at line 32 in MainPage.xaml.cs in the sample program with what's below it does not seem to make any difference. The new code would be:

private async void ChildPage_Async_Button_Clicked(object sender, EventArgs e)
{
    await Navigation.PushModalAsync(new NavigationPage(new ChildPage()));
}

The new NavigationPage(... is the changed bit and still when the child page is displayed there's no backbutton, is that what you meant or am I not getting it?

[XamlTest]

Verified this issue with Visual Studio Enterprise 17.3.0 Preview 1.0 [32427.455.main]. Repro on Windows with MultiPage-windowsmodal.zip

[PureWeen]

@david-maw why are you wanting to use a modal page here out of curiosity?

So this is by design. Modal Pages have never incorporated a visual back button. For example if you run this on iOS you just get a modal View on iOS with no back button and iOS has no physical back button. Usually modals are dismissable through other means like the user has completed some action on the modal view.

I could see an enhancement here where if you set "Shell.IsbackbuttonVisible" or something like that to true it would show it on modal but that's going to be an enhancement

[david-maw]

Thanks @PureWeen , the real App has a page which the user cannot navigate to directly from the Shell - basically it manipulates an image (it actually uses a web service to perform OCR on it) which must be selected first so it makes sense for the page to be modal because there's no other way to get to it and you must exit back from it to the more general page to act on the manipulated data (or cancel out of it).

It makes no sense to navigate somewhere else until the decision (keep the OCR data or not) is made. I imagine I could produce a scheme involving turning off shell navigation while on that page which would have pretty much the same effect as far as the user is concerned and if this is just a design decision, I could certainly live with it. I didn't want to use an extra button if the back button would do the job so some sort of "Shell.IsbackbuttonVisible" type scheme would work as well. Do you want to concert this to an enhancement request, or I can submit a separate one, whatever works best?

[dotMorten]

I'm quite confused about this as well. On Android it shows a backbutton and slides in from the bottom half way up. On Windows it replaces the entire view and you're stuck. The documentation says it's supposed to be a "popup":
https://learn.microsoft.com/en-us/dotnet/maui/user-interface/pop-ups#display-a-page-as-a-pop-up

[symbiogenesis]

If you want to use a popup, the MAUI Community Toolkit offers this feature, which would provide the ability to overlay a view on top of other views, while still showing the content underneath. And clicking outside of the popup content can be one way to close it.

https://learn.microsoft.com/en-us/dotnet/communitytoolkit/maui/views/popup