Port WindowChrome fix from 4.8

[SamBent]

Addresses Issue #4980. This is a port from a servicing fix in .NET 4.7-4.8.

Description

When the mouse moves between windows, WPF tries to avoid "flickering" the thread's input stream (deactivating, then immediately re-activating). The original logic decides that Deactivate is unnecessary when moving from window A to B if

• A and B both belong to the same Dispatcher, and
• The move ends in B’s client area

This doesn't work when B supplies its own chrome, and the move ends in the "effective" non-client area. The subsequent mouse events should go to DWM, not to either A or B. Leaving the thread's input stream active causes each event to be delivered both to DWM and to whichever of A or B is topmost at the mouse position.

Fixed by changing the second clause to be

• The move ends in B’s “effective” client area. (Excluding the invisible caption and resize-border areas declared by WindowChrome, if any.)

Customer Impact

Potential crash and data loss.

Regression

No. The problem has been lurking since the introduction of WindowChrome in .NET 4.5.

Testing

Ad-hoc around customer scenario.
Standard regression testing.

Risk

Low. Port of 4.8 servicing fix released earlier this year.

[batzen]

What about other custom chrome implementations (from ControlzEx for example)? Does the bug also affect those and if it does how can it be fixed there?

[batzen]

@SamBent @ryalanms No answer to my question?

[SamBent]

@batzen The answer depends on how the custom implementations work (which of course I don't know). All I can say for sure is that no one has reported this problem for other implementations, and the fix is necessarily directed at WPF's implementation.

The fix requires getting information about the "effective client area" that's not available via Win32 calls or any way that I could find, except by asking the WindowChrome object itself. Generalizing that to work for implementations that don't derive from WindowChrome would require defining public API (e.g. an interface) for asking and answering the question, and work on both sides to participate. This is well beyond the scope of a servicing fix (hence "necessarily" above).

If it's really a problem, open a new issue.