search

dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
22.19k stars 1.74k forks source link

Application.ModalPopped never fires when run in Unit Test. #6971

Open drasticactions opened 2 years ago

drasticactions commented 2 years ago

Description

I'm working on porting the KAMISHIBAI MVVM library from Xamarin.Forms to MAUI. I've bumped the version of Xamarin.Forms to the newest stable release and all of the tests pass. However, switching it over to MAUl, I have some failures.

In ApplicationAdapter_ModalPopped, the current Application should be posting an event when a modal window closes. This event never fires. For the Forms tests, this code works fine.

I made a MAUI Repo project where I attached to Application.ModalPopped, and those did fire correctly. But if I run the same code from a unit test project, it doesn't work.

MauiTempTest.zip

Any ideas?

image

image

CC @nuitsjp, since it's your library.

Steps to Reproduce

  1. Check out my branch (https://github.com/drasticactions/KAMISHIBAI/tree/maui-port/MAUI/Source)
  2. Open the solution
  3. Run the test ApplicationAdapter_ModalPopped

It shouldn't require extra dependencies or special versions of MAUI.

Version with bug

Release Candidate 2 (current)

Last version that worked well

Unknown/Other

Affected platforms

I was not able test on other platforms

Affected platform versions

This affects Testing Libraries. As far as I can tell, it does not affect the platforms themselves.

Did you find any workaround?

No response

Relevant log output

No response

nuitsjp commented 2 years ago

It seems that Navigation is not initialized without calling IApplication#CreateWindow, so it does not work correctly. Please check here.

drasticactions commented 2 years ago

Ahh, that makes sense. This still feels like an MAUI bug, though, since it probably should throw in that case if it's not set up correctly. And it could cause other issues down the line that are hidden.

PureWeen commented 2 years ago

@drasticactions yea this is a bit of an odd world. The Modal code was all moved to window because that's where it's relevant. Modal operations at the Application level don't really make any sense but for back compat we should probably just forward any calls at the Application to a single window if it's there or throw an exception if you are doing multiple windows.

AlexeyStarkov commented 2 years ago

It seems like those members related to Modals and Pages have to be removed from the Application class now when the application is based on Windows. Those events as well as MainPage property bring lots of confusion and collisions now. It feels like someone just forget to remove it after the framework had switched to the Window approach.

Example 1: MainPage returns the Page of the initial window (Windows[0]). For what? Why not the root page of the focused page? This MainPage property makes no sense to me taking into account the new multi-window approach. Even in the case of single window applications, it would be much more clear and more consistent to retrieve the page from Windows[0].

Example 2: When any window is closed, it is removed from the Windows collection. Any window, except the initial window (Windows[0]) because the MainPage property must keep the reference to the page of the initial window. As a result, when a user closes the initial window (having two or more windows opened), it disappears from the screen BUT stays in the Windows collection. Makes no sense to me. Moreover, such inconsistent behavior will be a source of bugs for sure.

Example 3: Every window has its own navigation stacks. So the modal page pushed by let's say Window[1] is put to the modal stack of Window[1]. But all of a sudden Application.ModalPushed is fired without any information about the window that owns that new modal page.

ghost commented 2 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

homeyf commented 1 year ago

Visual Studio Enterprise 17.8.0 Preview 2.0. Can repro on this issue with sample project. https://github.com/drasticactions/KAMISHIBAI/tree/maui-port/MAUI/Source