miloush
commented
2 years ago As much as I don't like what's happening here, I agree this is a WPF bug.
The ownership chain is MainWindow > Window1 > Window2 where the last two are shown using ShowDialog(). The repro is pulling a trick where Window1 enqueues an operation to close itself, which gets executed during the Window2 frame.
The issue is that when Window1 handles WM_CLOSE and decides to proceed with it, as per documentation:
By default, the DefWindowProc function calls the DestroyWindow function to destroy the window.
This results in the anticipated WM_DESTROY message, however, this comes with a caveat, as per documentation:
If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.
So when Window1 closes, Window2 gets a surprise WM_DESTROY without any preceding WM_CLOSE. And WM_CLOSE is where stopping the modal frame happens. The same bit, i.e.
should happen in WmDestroy too.
By the way, this repro also hits this codepath:
Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? No
Problem description: Window.Close() closes non-owned windows as documented.
See: https://docs.microsoft.com/en-us/dotnet/api/system.windows.window.close?view=windowsdesktop-6.0 Closing a Window causes any windows that it owns to be closed
Actual behavior:
ShowDialog() not returns on Close().
ShowDialog() returns on MainWindow close.
Expected behavior:
Owned windows are closed as documented.
ShowDialog() returns.
Minimal repro: WindowCloseBug.zip