Wpf: Any controls such as buttons are not hittest visible in non-client area (Windows Insider Preview only)

[walterlv]

• .NET Core Version: 3.1 / 5.0.100-Preview.8.20417.9
• Windows version: Windows 10 pro Insider Preview (2004) 20231.1005

• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

  Problem description:

1. Add any controls (such as buttons) on the non-client area of a WPF window.
2. Set the controls IsHitTestInChrome="True"
3. Embed any window as a child into a WPF window (using SetParent)
4. Hover or click the buttons on the non-client area.

Note: This bug only reproduces in the Insider Preview version after the 2004 version.

Actual behavior:

You'll find that the buttons don't work as the WPF behavior just like that the IsHitTestInChrome property is set to False. If we hook the window to detect the messages we'll find that no messages are received. But if the child window is released, the NCHITTEST message comes back again.

Expected behavior:

The messages are received as expected no matter the child window is in or out.

Minimal repro:

See here: https://github.com/walterlv/Walterlv.Issues.NonClientParent

[SamBent]

@walterlv Please open a bug against the OS about the failure to deliver WM_NCHITTEST messages, which is a breaking change of behavior in post-2004 preview builds. WPF can't fix this - we can't react to your clicks if the OS doesn't tell us about them.

[wjk]

@SamBent: Just curious. How should @walterlv go about opening a bug in the OS repo, when that repo has no public bug tracker and he does not work for Microsoft AFAICT? And please don't say Feedback Hub, as submissions there go nowhere and other MS repos do not even recommend using it unless necessary for collecting diagnostics. Feedback Hub has lost all credibility amongst Windows developers and users. Thanks!

[SamBent]

@wjk An MVP using an Insider Preview build should know how to open a bug. @walterlv Were you able to do so? If so, can we close this issue?

[SamBent]

Closing. WPF can't do anything about this.

There's been another report in the OS database, from an app-compat team. The app in question also used WindowChrome replace the OS non-client area with its own, using WindowStyle="SingleBorderWindow". The symptom was that clicking the app's Maximize button caused the app to close. Because the WM_NCHITTEST messages didn't go to the app's window, but rather to the (unseen) OS non-client area - so the click invokes the (unseen) OS Close button instead of the app's Maximize button that occupies the same space.