Allow the cursor to warp even when a window is dragged

ash/display/mouse_cursor_event_filter.cc

Index: ash/display/mouse_cursor_event_filter.cc
diff --git a/ash/display/mouse_cursor_event_filter.cc b/ash/display/mouse_cursor_event_filter.cc
index 9b6d2973cde40375253e5cd909298ce5305d84bc..889b8e949226aa0e09085e6ba08dd17edb08106b 100644
--- a/ash/display/mouse_cursor_event_filter.cc
+++ b/ash/display/mouse_cursor_event_filter.cc
@@ -6,6 +6,7 @@
 
 #include "ash/display/display_controller.h"
 #include "ash/shell.h"
+#include "ash/wm/coordinate_conversion.h"
 #include "ash/wm/cursor_manager.h"
 #include "ui/aura/env.h"
 #include "ui/aura/event.h"
@@ -31,14 +32,27 @@ bool MouseCursorEventFilter::PreHandleKeyEvent(aura::Window* target,
 
 bool MouseCursorEventFilter::PreHandleMouseEvent(aura::Window* target,
                                                  aura::MouseEvent* event) {
-  if (event->type() != ui::ET_MOUSE_MOVED ||
-      ash::Shell::GetInstance()->cursor_manager()->is_cursor_locked())
-    return false;
+  const bool is_cursor_locked =
+      Shell::GetInstance()->cursor_manager()->is_cursor_locked();
+
+  // When the cursor is not locked (i.e., nothing is dragged), we only handle
+  // ET_MOUSE_MOVED events. When it's locked, we only handle ET_MOUSE_DRAGGED
+  // events. This is because when the cursor enters the other root window while
+  // dragging, the underlying window system (at least X11) stops generating an
+  // ET_MOUSE_MOVED event.
+  if (!is_cursor_locked) {

[Daniel Erat, 2012/08/03 19:43:10]

This feels pretty strange to me.  I think of cursor locks as just being there to
make sure the cursor is drawn a certain way (e.g. maybe you want to hide it as
long as we're in a specific state).  Using them to determine how we should
respond to mouse events seems too subtle.

[Yusuke Sato, 2012/08/03 23:18:45]

I see. Stopped checking the lock status.

[Daniel Erat, 2012/08/06 14:52:00]

Sorry for not being more clear here.  I meant that it generally seems strange to
me to be using the cursor-lock status as a proxy for whether the pointer can be
warped or not.  It looks like this is still being done in DisplayController. 
I'd prefer that that class just had a more-general "allow_mouse_warp_" member
instead of "allow_mouse_warp_during_lock_", as the connection between having
locked the cursor and being able to warp the mouse is non-obvious to me.

[oshima, 2012/08/06 15:28:33]

Dan, you're right. Using lock status was short term solution until we have right
implementation.
Ideally, mouse move shouldn't be blocked at all, but we need to block it under
certain condition until
we figure out exactly how these operation should work.

Maybe we should have "dont_wrap_mouse_" flag and let resizer explicitly disallow
warp when resizing,
instead of allowing it when dragging.

[Yusuke Sato, 2012/08/06 17:30:14]

Done.

[Yusuke Sato, 2012/08/06 17:30:14]

Done. Stopped checking the mouse lock status in DisplayController. Please take
another look.

+    if (event->type() != ui::ET_MOUSE_MOVED)
+      return false;
+  } else {
+    if (event->type() != ui::ET_MOUSE_DRAGGED)
+      return false;
+  }
+
   aura::RootWindow* current_root = target->GetRootWindow();
   gfx::Point location_in_root(event->location());
   aura::Window::ConvertPointToWindow(target, current_root, &location_in_root);
   return display_controller_->WarpMouseCursorIfNecessary(
-      current_root, location_in_root);
+      current_root, location_in_root, is_cursor_locked);
 }
 
 ui::TouchStatus MouseCursorEventFilter::PreHandleTouchEvent(