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

ui/aura/root_window.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/aura/root_window.h"
 
 #include <vector>
 
 #include "base/bind.h"
 #include "base/command_line.h"
@@ skipping 758 matching lines @@
   }
 
   if (!dispatch_details.dispatcher_destroyed)
     dispatching_held_event_ = false;
   return dispatch_details;
 }
 
 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,
       base::Bind(base::IgnoreResult(&RootWindow::SynthesizeMouseMoveEvent),
                  held_event_factory_.GetWeakPtr()));
 }
 
 ui::EventDispatchDetails RootWindow::SynthesizeMouseMoveEvent() {
   DispatchDetails details;
   if (!synthesize_mouse_move_)
@@ skipping 152 matching lines @@
       break;
 
     default:
       NOTREACHED();
       break;
   }
   PreDispatchLocatedEvent(target, event);
 }
 
 }  // namespace aura