It turns out the situation is caused by thread state that Windows maintains. It is tested by WinUtils functions that are used in the DispatchMouseEvent call that was added to the WM_NCLBUTTONDOWN handler (and some other places). The global state tells things that the "synthesized" mouse event came from a pointer. The event isn't really "synthesized" -- it was just from a WM_NCLBUTTONDOWN (not a WM_POINTERDOWN) instead of a WM_LBUTTONDOWN -- but the thread state screws that up. We can circumvent the stuff that uses the invalid state pretty easily but we should try to find why it is making a difference to see if there is a more direct fix first. FYI, the WM_POINTER* messages were not relevant because there are WM_NCPOINTER* messages for the non-client area.
Bug 1736128 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
It turns out the situation is caused by thread state that Windows maintains (`GetMessageExtraInfo`). It is tested by WinUtils functions that are used in the DispatchMouseEvent call that was added to the WM_NCLBUTTONDOWN handler (and some other places). The global state tells things that the "synthesized" mouse event came from a pointer. The event isn't really "synthesized" -- it was just from a WM_NCLBUTTONDOWN (not a WM_POINTERDOWN) instead of a WM_LBUTTONDOWN -- but the thread state screws that up. We can circumvent the stuff that uses the invalid state pretty easily but we should try to find why it is making a difference to see if there is a more direct fix first. FYI, the WM_POINTER* messages were not relevant because there are WM_NCPOINTER* messages for the non-client area.