Aura: don't synthesize mouse moves while holding pointer.

ui/aura/root_window.cc

Index: ui/aura/root_window.cc
diff --git a/ui/aura/root_window.cc b/ui/aura/root_window.cc
index 128a04424d45ae084e9b6ecfbd659e1d1b42979a..f0647edd81734ba4fcc9aab91a174e2d6a53249c 100644
--- a/ui/aura/root_window.cc
+++ b/ui/aura/root_window.cc
@@ -776,6 +776,14 @@ ui::EventDispatchDetails RootWindow::DispatchHeldEvents() {
 void RootWindow::PostMouseMoveEventAfterWindowChange() {
   if (synthesize_mouse_move_)
     return;
+  // Don't synthesize mouse move while holding mouse.
+  // We also clear the held move event since held event target location may
+  // be wrong now (see comments in DispatchHeldEvents).
+  if (move_hold_count_) {
+    if (held_move_event_ && !dispatching_held_event_)
+      held_move_event_.reset();
+    return;

[sky, 2014/02/13 17:49:04]

If you do this, don't we need to ensure when mouse moves are reenabled an event
is generated? Could you write test coverage of this?

[dgozman, 2014/02/13 17:55:06]

There is already a drop of held moves on the line 764 above in the similar case.
Since I'm not that familiar with this stuff, I can't decide whether it's the
right thing to do. Do you have a strong opinion here?
The test I added verifies that nothing is sent. I will change it if behavior
changes.

+  }
   synthesize_mouse_move_ = true;
   base::MessageLoop::current()->PostNonNestableTask(
       FROM_HERE,