Synthesize an NSEvent for handling drag events, since we

can't guarantee that by the time we start dragging, the
application's current event is a valid drag.

BUG=16811 (http://crbug.com/16811)
TEST=Drag operations should all still work.

Review URL: http://codereview.chromium.org/171067

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23647 0039d316-1c4b-4281-b951-d872f2087c98

2 files changed, 18 insertions, 21 deletions

diff --git a/chrome/browser/cocoa/web_drag_source.mm b/chrome/browser/cocoa/web_drag_source.mm
index 6fd44a7..3e66832 100644
--- a/chrome/browser/cocoa/web_drag_source.mm
+++ b/chrome/browser/cocoa/web_drag_source.mm
@@ -200,12 +200,26 @@ void PromiseWriterTask::Run() {
 
 - (void)startDrag {
   NSEvent* currentEvent = [NSApp currentEvent];
+
+  // Synthesize an event for dragging, since we can't be sure that
+  // [NSApp currentEvent] will return a valid dragging event.
+  NSWindow* window = [contentsView_ window];
+  NSPoint position = [window mouseLocationOutsideOfEventStream];
+  NSTimeInterval eventTime = [currentEvent timestamp];
+  NSEvent* dragEvent = [NSEvent mouseEventWithType:NSLeftMouseDragged
+                                          location:position
+                                     modifierFlags:NSLeftMouseDraggedMask
+                                         timestamp:eventTime
+                                      windowNumber:[window windowNumber]
+                                           context:nil
+                                       eventNumber:0
+                                        clickCount:1
+                                          pressure:1.0];
+
   [contentsView_ dragImage:[self dragImage]
-                        at:[contentsView_
-                               convertPoint:[currentEvent locationInWindow]
-                                   fromView:nil]
+                        at:position
                     offset:NSZeroSize
-                     event:currentEvent
+                     event:dragEvent
                 pasteboard:pasteboard_
                     source:contentsView_
                  slideBack:YES];
diff --git a/chrome/browser/tab_contents/tab_contents_view_mac.mm b/chrome/browser/tab_contents/tab_contents_view_mac.mm
index 1b3877c..73c362c 100644
--- a/chrome/browser/tab_contents/tab_contents_view_mac.mm
+++ b/chrome/browser/tab_contents/tab_contents_view_mac.mm
@@ -84,23 +84,6 @@ void TabContentsViewMac::GetContainerBounds(gfx::Rect* out) const {
 }
 
 void TabContentsViewMac::StartDragging(const WebDropData& drop_data) {
-  // We are only allowed to call dragImage:... from inside mouseDragged:, which
-  // we will never be (we're called back async), but it seems that the mouse
-  // event is still always the proper left mouse drag, so everything works out
-  // in the end. However, we occasionally get spurious "start drag" messages
-  // from the back-end when we shouldn't. If we go through with the drag, Cocoa
-  // asserts in a bad way. Just bail for now until we can figure out the root of
-  // why we're getting the messages.
-  // TODO(pinkerton): http://crbug.com/16811
-  NSEvent* currentEvent = [NSApp currentEvent];
-  if ([currentEvent type] != NSLeftMouseDragged) {
-    LOG(INFO) << "Spurious StartDragging() message";
-    RenderViewHost* rvh = tab_contents()->render_view_host();
-    if (rvh)
-      rvh->DragSourceSystemDragEnded();
-    return;
-  }
-
   // The drag invokes a nested event loop, but we need to continue processing
   // events.
   MessageLoop::current()->SetNestableTasksAllowed(true);