mus: Implement interwindow drag and drop

services/ui/ws/event_dispatcher.cc

Index: services/ui/ws/event_dispatcher.cc
diff --git a/services/ui/ws/event_dispatcher.cc b/services/ui/ws/event_dispatcher.cc
index 3890db7bb4bc43bd2fa893296d11ec19d1e64634..0565063ceb28947dbe06c3fa8a84ee353babe99f 100644
--- a/services/ui/ws/event_dispatcher.cc
+++ b/services/ui/ws/event_dispatcher.cc
@@ -8,6 +8,8 @@
 
 #include "base/time/time.h"
 #include "services/ui/ws/accelerator.h"
+#include "services/ui/ws/current_drag_operation.h"
+#include "services/ui/ws/current_drag_operation_source.h"
 #include "services/ui/ws/display.h"
 #include "services/ui/ws/event_dispatcher_delegate.h"
 #include "services/ui/ws/server_window.h"
@@ -179,6 +181,19 @@ bool EventDispatcher::SetCaptureWindow(ServerWindow* window,
   return true;
 }
 
+void EventDispatcher::SetDragDropSourceWindow(
+    CurrentDragOperationSource* drag_source,
+    ServerWindow* window,
+    mojo::Map<mojo::String, mojo::Array<uint8_t>> mime_data,
+    uint32_t drag_operations) {
+  current_drag_drop_operation_.reset(new CurrentDragOperation(

[sky, 2016/09/06 21:11:27]

MakeUnique is the new hotness.

Should this implicitly change capture? What do we do in the aura side now?

[Elliot Glaysher, 2016/09/07 21:42:23]

The normal ash drag controller implicitly takes capture on the beginning of a
drag.

[sky, 2016/09/07 23:25:29]

Relying on ash to have done before calling this is error prone and racy. If we
need to ensure capture is set we should either fail if capture isn't set, or
implicitly grab capture if not already grabbed.

+      drag_source, window, std::move(mime_data), drag_operations));
+}
+
+void EventDispatcher::EndDragDrop() {
+  current_drag_drop_operation_.reset();
+}
+
 void EventDispatcher::AddSystemModalWindow(ServerWindow* window) {
   modal_window_controller_.AddSystemModalWindow(window);
 }
@@ -287,6 +302,11 @@ void EventDispatcher::ProcessKeyEvent(const ui::KeyEvent& event,
                                       AcceleratorMatchPhase match_phase) {
   Accelerator* post_target =
       FindAccelerator(event, ui::mojom::AcceleratorPhase::POST_TARGET);
+  if (current_drag_drop_operation_ && event.type() == ui::ET_KEY_PRESSED &&
+      event.key_code() == ui::VKEY_ESCAPE) {
+    current_drag_drop_operation_->DispatchCancel();
+    return;
+  }
   ServerWindow* focused_window =
       delegate_->GetFocusedWindowForEventDispatcher();
   if (focused_window) {
@@ -328,6 +348,12 @@ void EventDispatcher::ProcessPointerEvent(const ui::PointerEvent& event) {
       mouse_button_down_ = false;
   }
 
+  if (current_drag_drop_operation_) {
+    const PointerTarget target = PointerTargetForEvent(event);

[sky, 2016/09/06 21:11:27]

Won't an early return potentially leave pointer_targets_ in the wrong state?

[Elliot Glaysher, 2016/09/07 21:42:23]

Maybe I'm misunderstanding this, but why is this a problem when sending a mouse
event to an explicitly captured when isn't?

[sky, 2016/09/07 23:25:29]

As long as you ensure capture is present, then I agree this early return is ok.
That said, what happens if capture changes part way through the drag? Should the
drag be canceled? If not, things are in a bad state.

+    current_drag_drop_operation_->DispatchLocatedEvent(event, target.window);
+    return;
+  }
+
   if (capture_window_) {
     mouse_cursor_source_window_ = capture_window_;
     DispatchToClient(capture_window_, capture_window_client_id_, event);