GitLab

Don't track mouse events in HWNDMessageHandler when they are forwarded by the LegacyRenderWidgetHostHWND class.

We use the TrackMouseEvent API in HWNDMessageHandler when we receive a WM_MOUSEMOVE message. This is to ensure that Windows sends us a WM_MOUSELEAVE
message when the cursor leaves our window bounds. Tooltips use this message to dismiss the tooltip for e.g.

Technically when the mouse enters the child window (LegacyRenderWidgetHostHWND) it has left the parent window. We end up getting WM_MOUSELEAVE messages
for WM_MOUSEMOVES which are sent to the parent window by the LegacyRenderWidgetHostHWND class causing tooltips to not show up and some other bugs.

Fixes as below:-
1. Add a special marker in the hiword of the WPARAM in WM_MOUSEMOVE messages sent by the LegacyRenderWidgetHostHWND class. This is to indicate to the parent
   that it should not track these mouse moves.
2. When we lose activation in HWNDMessageHandler we post a dummy WM_MOUSELEAVE message. This is enable tooltips if they were visible to be dismissed for e.g
   Based on code inspection a WM_MOUSELEAVE message should not cause any issues.
3. Forward WM_MOUSEWHEEL and WM_MOUSEHWHEEL messages via SendMessage to the parent without mucking with the parameters. The offsets are in screen coordinates in
   these messages.
4. Reposting events today fails when we click on the (LegacyRenderWidgetHostHWND) HWND. This is because the current code attempts to find an aura Window at the
   location which fails. I changed the RepostLocatedEvent function to allow a NULL window parameter on Windows. We attempt to forward the event to the HWND at the
   current location if it is on the same thread.

BUG=342323,342298,342299,341879,343246
R=cpu@chromium.org, sky@chromium.org, sky

Review URL: https://codereview.chromium.org/159713012

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251190 0039d316-1c4b-4281-b951-d872f2087c98