Ignore (fake) mouse events that are created during a touch (iff we will handle the touch elsewhere.)

Ignore (fake) mouse events that are created during a touch (iff we will handle the touch elsewhere.)

BUG=129638
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=139730

[girard, 2012-05-30 20:52:26]

When the OS detects a touch event, it creates some fake WM_MOUSE* messages that
are flagged as such.  We now ignore these if we are already handling the
WM_TOUCH events.

[sky, 2012-05-30 22:44:16]

See
http://msdn.microsoft.com/en-us/library/windows/desktop/dd693088(v=vs.85).aspx .
It indicates you should be more restrictive in what you check for. I added code
like this to NativeWidgetWin here:
http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/widget/native_widget...
.

[girard, 2012-05-31 00:02:41]

When the OS detects a touch event, it creates some fake WM_MOUSE* messages that
are flagged as such.  We now ignore these if we are already handling the
WM_TOUCH events.
(Current revision is much more strict in what it ignores, testing for specific
flags and messages.)

[sky, 2012-05-31 00:44:14]

LGTM - I'm surprised you need this. I would have thought by processing WM_TOUCH
the system wouldn't generate mouse events.

https://chromiumcodereview.appspot.com/10454082/diff/2002/content/browser/ren...
File content/browser/renderer_host/render_widget_host_view_win.cc (right):

https://chromiumcodereview.appspot.com/10454082/diff/2002/content/browser/ren...
content/browser/renderer_host/render_widget_host_view_win.cc:1806: message ==
WM_RBUTTONDOWN || message == WM_RBUTTONUP) &&
nit: indent this line one more space.

[girard, 2012-05-31 01:04:34]

On 2012/05/31 00:44:14, sky wrote:
> LGTM - I'm surprised you need this. I would have thought by processing
WM_TOUCH
> the system wouldn't generate mouse events.
> 
>
https://chromiumcodereview.appspot.com/10454082/diff/2002/content/browser/ren...
> File content/browser/renderer_host/render_widget_host_view_win.cc (right):
> 
>
https://chromiumcodereview.appspot.com/10454082/diff/2002/content/browser/ren...
> content/browser/renderer_host/render_widget_host_view_win.cc:1806: message ==
> WM_RBUTTONDOWN || message == WM_RBUTTONUP) &&
> nit: indent this line one more space.

I was a little surprised too.  It appears that when we've registered for touch
messages, Windows still generates mouse events.  Most of the events (button up
and down, left and right) can be identified by GetMessageExtraInfo(), but the
WM_MOUSEMOVE messages return 0 from GetMessageExtraInfo().  So even now we'll be
passing those through.

[commit-bot: I haz the power, 2012-05-31 01:10:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/girard@chromium.org/10454082/6001

[commit-bot: I haz the power, 2012-05-31 04:40:56]

Change committed as 139730