The WindowChrome class needs to be updated & fixed

[AzAgarampur]

• .NET Core Version: 3.1.6
• Windows version: (10.0.19042)
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

Problem description:

The WindowChrome class that allows us to customize the non-client area of WPF windows has a few bugs. First, the sizes for the window frame are not correct and do not represent the correct default window frame sizes.

In addition, this class has not been updated for Windows 10. Ever since Windows 10, the right, left, and bottom non-client frames are transparent except for a 1px border which is what gives windows their "borderless" look. When using WindowChrome on Windows 10, this is not taken into consideration.

The following XAML code will show the current problems with the WindowChrome class.

XAML: <WindowChrome/>

There are some problems as you can see:

1. The size of all the extended window frames are too small.
2. On Windows 10, the transparent side non-client frames are not being taken into account.

In order to fix the side border issues on Windows 10, we need to make the XAML the following: <WindowChrome NonClientFrameEdges="Bottom,Left,Right"/> Consider making this the default behavior on Windows 10. However, this fixes only the side border problem, as the titlebar is still too small. Also, even though the side border do look fixed, the amount of non-client border that has been brought back is too little (due to the size of all the extended window frames being too small.) This results in:

We need the correct extended frame sizes fixed first, because it not only messes up the look of the extended window frame borders, but it also will cause problems when an app is maximized, because the too small frame hangs over the monitor, which can result in transparent holes in the app's UI.

Next, it seems like WM_NCMOUSELEAVE is not being handled properly. There are times when the mouse quickly moves over the extended frame's caption buttons then leaves, but the highlight is not removed from the caption button. This picture shows this phenomenon happening on the close button, but it happens on all buttons:

[ClosetBugSlayer]

All of these bugs relate to WindowChrome.

#3675 #2242 #3193 #1176 #1269

[AzAgarampur]

Majority of the problems mentioned are because of incorrect nonclient dimensions gathered by WindowChrome. #1176 is also another longtime bug I wish gets fixed ASAP but I think it has to do more with the DirectX compositor and how it handles the window styles more than a problem with the WindowChrome class itself.

[crypto-rsa]

There is also a StackOverflow issue when using a custom WindowChrome in a window with SizeToContent set to WidthAndHeight. Not sure if it would be fixed by any of the mentioned issues.

[GF-Huang]

Similar issue. WindowChrome has different appearance on Win11 21H2 and Win11 22H2.

In this issue (HandyOrg/HandyControl#1277), although I mentioned the difference in how hc:Window and Window look on Win11 22H2, but I found that the hc:Window works well on Win11 21H2 but incorrect on Win11 22H2.

Works well means there is not black border at the top of the app window.

[NickeManarin]

Another weird bug, when you have NonClientFrameEdges="Left" (or any combination with Left value) and UseAeroCaptionButtons="True" and some style setting is changed in Windows Settings (like the accent color), the content of the window will slowly (over the course of 1-2s) shift to the left by ~50px.

If you have Right, the window content may shift back to the correct position.