Automated test is being worked on (and almost ready for a review) at https://codereview.chromium.org/2507223003

Thanks for catching!  Paul is OOO, so maybe we can track this down in the meantime?  Ken, are you familiar with the coordinate logic here?

I think I need to clarify that by "coordinates" I mean the value of clientX, clientY and pageX, pageY DOM event properties.

I also wonder what happens for other events fired when the mouse is over another frame (i.e. for mouseleave) - i.e. if there is a difference in clientX/Y properties between OOPIF and non-OOPIF case.  FWIW, a stack overflow post (*) seems to indicate that Internet Explorer sets clientX and clientY to -1 when firing a mouseleave event.

(*) http://stackoverflow.com/questions/34026626/is-there-a-way-to-identify-mouse-leave-specifically-to-the-top-in-ie

Re comment #3: MouseLeave is handled explicitly in the browser process, dispatched to frames being exited by RenderWidgetHostInputEventRouter. It includes translated coordinates, and I think we need to do something similar here.

Looking at the link, they are talking about the top-level window, and we set the DragLeave coordinates to (0, 0) if we drag out of it. Moving out of a frame while remaining in the window, I don't think we want to change existing behavior (looking at it since our last discussion, it looks fairly significant). The right thing is likely to plumb coordinates in the DragMsg_DragTargetDragLeave message.

 Issue 682198  has been merged into this issue.

 Issue 682197  has been merged into this issue.

I think Ken is actually the one working on this, right?  Paul, feel free to assign it back if you plan to fix it.

FWIW, I've pushed the test page to github, so that we can more easily drag-and-drop with other browsers: https://anforowicz.github.io/drag-and-drop/page.html

I've tested what coordinates (i.e. event.clientX and event.clientY) "dragend" event reports, if the drop occurs outside of the browser window (e.g. when dropping the dragged image onto desktop).  This scenario is somewhat similar to the situation where the drop occurs in another (potentially cross-site) frame.
- Win/Chrome 56.0.2924.76 and Edge 25.10586.672.0 (EdgeHTML 13.10586) and Safari 10.0.2 (12602.3.12.0.1) report coordinates relative to the drag-source frame (although in case Safari [or maybe MacOS] the coordinates are weird - the Y axis is flipped upside-down outside of the browser window).
- Win/Firefox 51.0.1 reports (0,0).  This occurs even if the drop happens in another same-origin frame.

Given above, I think it is okay to for now disclose to the drag-source frame the coordinates of events happening outside of the frame/window.  If needed we can tackle this as a separate (low priority IMO) bug.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/07c272807932376eafddce27c267028b42ba6c31

commit 07c272807932376eafddce27c267028b42ba6c31
Author: kenrb <kenrb@chromium.org>
Date: Tue Feb 07 23:48:17 2017

Correctly set dragLeave and dragEnd coords for OOPIF drag and drop

Currently dragLeave events triggered from the browser process always
have (0, 0) set as coordinates, which is incorrect when the mouse
cursor has not left the page. This patch sets the correct coordinates
when the cursor moves between frames of different processes.

Also, dragEnd event coordinates were not being correctly transformed
before being passed to the target RenderWidgetHost. This patch
applies the transform to move the coordinates into the correct
coordinate space for the frame that receives the dragEnd.

BUG= 669695 

Review-Url: https://codereview.chromium.org/2655463015
Cr-Commit-Position: refs/heads/master@{#448797}

[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/chrome/browser/ui/views/drag_and_drop_interactive_uitest.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/components/test_runner/event_sender.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/browser_plugin/browser_plugin_guest.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/web_contents/web_contents_view_android.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/web_contents/web_contents_view_aura.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/web_contents/web_drag_dest_mac.mm
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/browser/web_contents/web_drag_source_mac.mm
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/common/drag_messages.h
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/public/browser/render_widget_host.h
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/renderer/render_widget.cc
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/content/renderer/render_widget.h
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/third_party/WebKit/Source/web/WebFrameWidgetBase.cpp
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/third_party/WebKit/Source/web/WebFrameWidgetBase.h
[modify] https://crrev.com/07c272807932376eafddce27c267028b42ba6c31/third_party/WebKit/public/web/WebFrameWidget.h

Ken, can this be marked as fixed after r448797?