Extended AppWindow titlebar top border not visible on Windows 10
Describe the bug
When having a custom titlebar using ExtendsContentIntoTitleBar the top border of the app will dissapear.
Steps to reproduce the bug
- Create an empty project
- Configure the titlebar
public MainWindow()
{
AppWindow.TitleBar.ExtendsContentIntoTitleBar = true;
}
- Run the app
Expected behavior
I would expect to see the top border, same way we can see it when using MainWindow.ExtendsContentIntoTitleBar.
Now that the API is supported on Windows 10 too, it should work as it's not a compatibility problem anymore.
Screenshots
This is how it looks on Windows 10.
This is how it looks on Windows 11.
NuGet package version
Windows App SDK 1.8.3
Packaging type
Packaged (MSIX)
Windows version
Windows 10 version 22H2 (19045)
IDE
Visual Studio 2022
Additional context
This issue is in WinAppSdk 1.2 as well.
Many windowing frameworks have this problem as well. It is because the border is created by the non-client area frame. The left, right, and bottom edges of the window are extended non-client areas created during the processing of WM_NCCALCSIZE. The top border is an extended frame using DwmExtendFrameIntoClientArea or may not have an extended frame. Either way, on Windows 10 extended frames do not have a border line. You need to draw it in manually like ApplicationFrameHost which draws UWP windows does.
This is also an issue in Windows 11 - when using HighContrast modes.
Even if you try to compensate for the missing top border, by adding one - there doesn't seem to be an Inactive state/event you can detect to swap out resources.
Many windowing frameworks have this problem as well. It is because the border is created by the non-client area frame. The left, right, and bottom edges of the window are extended non-client areas created during the processing of
WM_NCCALCSIZE. The top border is an extended frame usingDwmExtendFrameIntoClientAreaor may not have an extended frame. Either way, on Windows 10 extended frames do not have a border line. You need to draw it in manually likeApplicationFrameHostwhich draws UWP windows does.
This is not an excuse of winui3 not handling it well (I believe winui team could just handle it in the window proc to draw that row of pixels and not affecting 99.9% of the scenarios, like who would ever put controls in that top 1px) and definitely not an excuse of throwing the responsibility to us developers. The winui3 gallery is supposed to be a demo and a reference, but now all we have
is this obtrusive bug.
Related to #6901
Still reproducing in 1.8.3.