INavigation.PopModalAsync fires ApplyQueryAttributes

[Ghostbird]

Description

Given the web-like routing metaphor used in MAUI, I was unpleasantly surprised by the fact that INavigation.PopModalAsync fires the ApplyQueryAttributes on the underlying page.

It seems there are two schools of though in this.

1. Those that think query attributes on routes are one-time data: Navigation data is retained and also presented to IQueryAttributable on Back navigation. #10294
2. Those who like me embrace the web-like routing metaphor and think the query attributes are a persistent and fundamental part of the route.

No matter which of these views you ascribe to, in both cases INavigation.PopModalAsync should not call ApplyQueryAttributes on the underlying page.

Both schools of thought will not expect it for these respective reasons:

1. The query attributes are one-time data, they're gone after the first time the page was loaded.
2. In web-like routing specifically loading a modal is not a navigation action that affects the underlying page. In fact, in the web that is almost exclusively the exact use case of modals. The ability to show the user a different UI, without changing anything to the underlying page. The modal behaviour should be "pure" with respect tot the underlying page. Only the final result of user interaction in the modal may be received by the caller, and the caller may act upon it. The most common use case I can think of is when you open a modal with a cancel button. The entire point is that the user can interact with a different UI, but when they cancel their action, the underlying page is completely unchanged.

Steps to Reproduce

1. Navigate to a page that implements IQueryAttributable
2. Call await Application.Current!.MainPage!.Navigation.PushModalAsync()
3. Call await Application.Current!.MainPage!.Navigation.PopModalAsync()

You'll see that ApplyQueryAttributes fires on the page from step 1.

Link to public reproduction project repository

I don't think a reproduction is necessary. This warrants a discussion on the desired behaviour.

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

Android, I was not able test on other platforms

Affected platform versions

Android 12+ tested, but I think this is a general MAUI issue.

Did you find any workaround?

My colleague @Hobbes1987 came up with a workaround that works specifically for pages that you can route to, and that pop and push modals, but do not push and pop pages. This is good enough for me for now.

1. Every navigation to an affected page should pass in an additional query parameter instanceId that's a random value.
2. Every affected page should have an InstanceId state.
3. ApplyQueryAttributes should return immediately if the passed dictionary's instanceId value matches the page's state InstanceId.

Relevant log output

No response

[bakerhillpins]

I'll link my comments here rather than duplicate as I believe what you describe here is the same as #10294.

Given the web-like routing metaphor used in MAUI, I was unpleasantly surprised by the fact that INavigation.PopModalAsync fires the ApplyQueryAttributes on the underlying page.

It seems there are two schools of though in this.

Web apps and MAUI should not be construed to be identical in behavior because they share the same outward facing conceptual constructs (Uri).

[mattleibow]

@PureWeen FYI

[PureWeen]

The most common use case I can think of is when you open a modal with a cancel button.

Yea this makes sense. I think historically Pages themselves never really had any context of Navigation. They had the Appearing event but that event was vague and inconsistent in Xamarin.Forms so the ApplyQueryAttribute acted a bit like "Hey you just got navigated to".

Now that all of the pages have Navigating/Navigated events there's a bit more context the page can use. Ideally, we'd expand some parameters into those that indicate if you are being popped to/from which I think would also help here.

The other area here that I think is a bit overloaded are Modals themselves. Right now, the Modal features cover more scenarios than I think they should. We added a way to set the background to transparent to "fake" dialogs. This "magic" has always been a pain to maintain and really awkward for accessibility. Ideally, we'd have more proper popups/dialogs that could host more interesting content.

I don't think we can just jump directly to no longer calling ApplyQueryAttributes for purposes of breaking changes.

From the workaround you posted it seems like if you had a bit more contextual information that might also help? For example, can you use the NavigatedTo event on the Page? Could you use the Shell.Navigated event and then pass that context to the current page to indicate whether it was popped to and from?

Honestly, I think there's a future here where the Navigating/Navigated events will gain parameters and then you can use these with non-shell pages as well.

[Ghostbird]

Yeah, I think I got a bit confused by the new web style routing that the appshell uses. Once you're in that line of thinking, and you're used to web design, your expectations can be way off.
While I like the simplicity of IQueryAttributable, as @PureWeen says, the best way to get more context would probably be through the Naviging/Navigated events.

Should I close this issue, or should I leave it open as a discussion point? Clearly this is not a bug. More a potentially confusing aspect of the new routing, and potential ways to improve upon it.

[Ghostbird]

This is a very useful approach that I'm using now, which completely eliminates the problem, regardless of whether you return to a page by route or pop.