Bug 1563918 - Avoid spamming native message loop with WM_NCMOUSELEAVE messages. r=jmathies

In bug 1551961, a WM_NCMOUSELEAVE message handler was added to the Windows widget
backend so that we can detect when the mouse leaves a draggable region (since
draggable regions are hittest'ed as HTCAPTION, and are therefore "non-client").

Inside that message handler, we used the WindowAtMouse handler to determine whether
or not the WM_NCMOUSELEAVE was firing because the mouse was moving off of the
non-client area to client area, or moving out of the window entirely.

For reasons that are not particularly clear, on Windows Aero Glass, when clicking on
one of the min/max/close caption buttons, a WM_NCMOUSELEAVE message fires, and the
::WindowFromPoint call that WindowAtMouse uses causes another WM_NCMOUSELEAVE message
to be queued immediately after, so we end up in this situation where the message
loop is getting spammed by WM_NCMOUSELEAVE messages. Moving the mouse away from
the caption buttons seems to stop the spamming.

We have a function similar to WindowAtMouse called EventIsInsideWindow which
does not use ::WindowFromPoint, and this seems to sidestep the issue, while
being functionally equivalent.

Depends on D37421

Differential Revision: https://phabricator.services.mozilla.com/D37422

--HG--
extra : moz-landing-system : lando

widget/windows/nsWindow.cpp

@@ -5393,7 +5393,7 @@ bool nsWindow::ProcessMessage(UINT msg, WPARAM& wParam, LPARAM& lParam,
     case WM_NCMOUSELEAVE: {
       mMouseInDraggableArea = false;
 
-      if (WindowAtMouse() == mWnd) {
+      if (EventIsInsideWindow(this)) {
         // If we're handling WM_NCMOUSELEAVE and the mouse is still over the
         // window, then by process of elimination, the mouse has moved from the
         // non-client to client area, so no need to fall-through to the