-
Mike Conley authored
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
b5ab3772