Double-click sometimes incorrectly maximizes the application

[pomianowski]

Describe the bug
Sometimes when you trigger the maximizing by double-clicking on the TitleBar, the application is immediately maximized and restored.

To Reproduce

1. Open one or two demo app's
2. Several times maximize and restore using double-click / dragging from maximized window
3. See error

Expected behavior
Double click always maximizes the application from its normal state.

Screenshots

Desktop:

• OS: Windows 11 Education 22000.1.amd64fre.co_release.210604-1628
• .NET: 6.0.101
• Version: 1.2.2-prerelease133

Additional context
#36
/ Multimonitor setup - 3440x1440 (125%) [Landscape] + 1080x1920 (125%) [Portrait]

[pomianowski]

@Aelarion #36 (comment) related

[Aelarion]

I'm having trouble reproducing this, but just looking through the code I think the RootGrid.MouseDown handler might be clashing with RootGrid.MouseMove handler:

wpfui/WPFUI/Controls/TitleBar.cs

Lines 504 to 510 in a0795c3

	private void RootGrid_MouseDown(object sender, MouseButtonEventArgs e)
	{
	if (e.ChangedButton != MouseButton.Left)
	return;
	ParentWindow.DragMove();
	}

Both of these handlers are looking for the mouse to be pressed, however the MouseDown handler is going to take priority since it will fire as soon as the button is down, whereas the MouseMove handler is going to wait until the mouse is moved by whatever amount of pixels the system decides is "enough" to fire, and the logic inside of that handler is to do nothing unless the left mouse button is pressed.

Since the MouseDown event will take priority, it is triggering the ParentWindow.DragMove() call as soon as the button is down. This may affect how the window messages are being sent for window states and such.

Looking at the RootGrid.MouseDown event -- I think we could quite easily just combine that into RootGrid.MouseMove handler, since it is already doing the left mouse button check anyway. Realistically this just boils down to moving the ParentWindow.DragMove() outside of the IsMaximized check in RootGrid.MouseMove handler, and we get rid of the RootGrid.MouseDown handler altogether.

Change:

if (e.LeftButton != MouseButtonState.Pressed || ParentWindow == null) return;
if (IsMaximized)
{
    ...
    ParentWindow.DragMove();
}

To:

if (e.LeftButton != MouseButtonState.Pressed || ParentWindow == null) return;
if (IsMaximized)
{
    ...
}
ParentWindow.DragMove();

Edit: logic clarification

[Aelarion]

@pomianowski disregard my previous comment -- it's so much simpler...

To reproduce this issue, place the window towards the top of your screen, so that the TitleBar will be under your mouse when you double click it. Somewhere in here, this is triggering the RootGrid.MouseMove event, even though the mouse is not moving. As a result, it is triggering the "restore-drag" functionality without the mouse moving... 🤦

EDIT: After doing some inspection on the mouse position, it looks like this is firing because the mouse coordinates with respect to the control are changing when the window is resized (e.g. the width is increased when maximized and the window location is moved, so the mouse X coordinate changes on the grid -- therefore the MouseMove event gets fired).

I'll work on this one, should be fairly straightforward to correct.