Could this be due to some of the refactoring work around pointer events?

This seems mysteriously around the time paul worked on the drag and drop end. kenrb@ did you check with paulmeyer@

Specifically change: https://chromium.googlesource.com/chromium/src/+/8fc8ea94ab9b37dc2fab2beeb6bff3180685d2d5

Hm, we have a layout test in Blink where the drag source is in an iframe [1], but we don't have one where the target is in an iframe. The test was aded to fix  https://crbug.com/618770 

I'll write the test where the target is in an iframe, as having it seems worthwhile. I'll update this if I find anything interesting.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/dnd/event-mouse-coordinates-iframe.html

Also... after verifying that clientX / clientY are different in M55 and M58, I was about to add the Needs-Bisect label, but I can't help but wonder if we're doing the right thing in M55.

IIRC, clientX / clientY should be relative to the current frame... so they're completely meaningless if the drop is in another frame. It seems to me that we should report something like null or undefined, both in this case and in the case of dropping outside the browser window. Any thoughts on this?

RE: #c5

- I agree - this is what I was suggesting in  https://crbug.com/669695#c3 .
- I think similar reasoning might apply to mouseleave event when the mouse leaves the frame.
- OTOH, I haven't done any research into what other browsers are doing (other than finding the stack overflow post mentioned in  https://crbug.com/669695#c3 ).

Do you know when we can expect a fix ?

clientX is "The horizontal coordinate at which the event occurred relative to the viewport associated with the event."

Which viewport would we say is associated with the event? If the event fires in the source frame, I'd say the event is associated with the source frame.

I don't think clientX/Y can be relative to a frame other than the one that received the event, in cross-process cases there is no way that that can be useful.

In response to comment 5, it isn't necessarily meaningless if it is dropped outside the frame, because (absent this bug) the source frame can do things like compute the X and Y difference between the dragStart and the drop. Assigning (0, 0) to an out-of-frame drop just as you do for an out-of-window drop might be reasonable, but could carry a risk of breaking web sites.

Any updates regrading this bug? When a fix is expected? Thanks

#11: This issue is available -- it hasn't been picked up by any developer. I don't have time to work on it for M58, for sure.

Navid can you examine this when you have time?

 Issue 742054  has been merged into this issue.

This is going to be worse with the slow-path targeting happening in M65 (in some cases, we will be targeting the wrong view for drag-update/drop events)