microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.84k stars 320 forks source link

Closing a child window causes a crash in a WinUI3 XAML-hosted application. #4016

Open Ajith-GS opened 11 months ago

Ajith-GS commented 11 months ago

Describe the bug

In a WinUI 3 XAML-hosted application, when closing an explicitly created child window, it throws exception and causes application crash. We are creating and activating a WinUI 3 window using a button click handler available in the XAML page, which is hosted over the native application. In this scenario, should we do any extra handling to close the newly created window properly? Any help is appreciated.

Steps to reproduce the bug

  1. Download and build the XAML Island sample application available in the following repo. https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Islands
  2. Add the following lines of code inside the WinUI button click handler available in the "MainPage" cpp file.
    auto ChildWindow = Microsoft::UI::Xaml::Window();
    ChildWindow.Activate();
  3. Build and run the application.
  4. Click the WinUI 3 button.
  5. Close the newly created WinUI 3 window using close icon.

Expected behavior

The window should close without any exception, and the parent app should continue to run as it is.

Screenshots

No response

NuGet package version

Windows App SDK 1.4.3: 1.4.231115000

Packaging type

Unpackaged

Windows version

Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022

Additional context

The same behavior is found if we create an XAML window using the Blank Window (WinUI 3 in Desktop) template and activate it inside the button click handler.

JesseCol commented 11 months ago

Hi there -- yes, thank you for the bug report! The bug here is that when the last Xaml Window goes away, it does a PostQuitMessage(), which exits the message loop, causing the process to exit. I'm hoping we can get a fix into WinAppSDK.

If you need this to work, there's an ugly workaround you could do here. Usually, a message loop will exit when GetMessage() returns FALSE. When the Xaml runtime calls PostQuitMessage(), the GetMessage() call in your message loop will soon return FALSE. You can dodge this FALSE if you know it's coming by ignoring it and continuing the loop anyway. I can add more detail if you're interested in trying this.

Ajith-GS commented 11 months ago

Hi there -- yes, thank you for the bug report! The bug here is that when the last Xaml Window goes away, it does a PostQuitMessage(), which exits the message loop, causing the process to exit. I'm hoping we can get a fix into WinAppSDK.

If you need this to work, there's an ugly workaround you could do here. Usually, a message loop will exit when GetMessage() returns FALSE. When the Xaml runtime calls PostQuitMessage(), the GetMessage() call in your message loop will soon return FALSE. You can dodge this FALSE if you know it's coming by ignoring it and continuing the loop anyway. I can add more detail if you're interested in trying this.

Hi,  Thank you for the reply. We would like to try this workaround, and it would be highly appreciated if you could provide more details.

Ajith-GS commented 9 months ago

Hi there -- yes, thank you for the bug report! The bug here is that when the last Xaml Window goes away, it does a PostQuitMessage(), which exits the message loop, causing the process to exit. I'm hoping we can get a fix into WinAppSDK.

If you need this to work, there's an ugly workaround you could do here. Usually, a message loop will exit when GetMessage() returns FALSE. When the Xaml runtime calls PostQuitMessage(), the GetMessage() call in your message loop will soon return FALSE. You can dodge this FALSE if you know it's coming by ignoring it and continuing the loop anyway. I can add more detail if you're interested in trying this.

Hi, Could you please share more information on this workaround? It would be very helpful for us.