When dragging content from an iframe on macOS, the drag image location is computed incorrectly if the iframe is not at (0, 0). To reproduce, try dragging the logo in <https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_draganddrop>. Reproduces on Safari 11 and later (on macOS 10.13, the drag image is clamped to the mouse cursor with an animation, so it looks like the drag image flies in from offscreen).
This is fallout from refactoring in r218837.
Created attachment 331828 [details] Reduced test case
<rdar://problem/35479043>
Created attachment 331830 [details] Patch
*** Bug 179733 has been marked as a duplicate of this bug. ***
Comment on attachment 331830 [details] Patch Thanks for the review!
Comment on attachment 331830 [details] Patch Manually landed r227266: <https://trac.webkit.org/changeset/227266> Commit queue doesn't seem to be processing this patch...
> Commit queue doesn't seem to be processing this patch... Tracking in https://bugs.webkit.org/show_bug.cgi?id=181907
Comment on attachment 331830 [details] Patch No test?
(In reply to Simon Fraser (smfr) from comment #9) > Comment on attachment 331830 [details] > Patch > > No test? (from the ChangeLog:) "Since this bug only affects drag and drop in the macOS WebKit2 port, there's currently no way to test this. I'll be using <https://bugs.webkit.org/show_bug.cgi?id=181898> to track adding test support for drag and drop on macOS WebKit2. Manually tested dragging in both WebKit1 and WebKit2 on macOS. dragLocationInWindowCoordinates isn't used at all for iOS drag and drop." I've begun investigating drag and drop testing support for macOS using WebKit2, but this would require significant (feature level) work, which I don't think this fix should be blocked on. The infrastructure needed to write cross-platform WebKit2 drag and drop tests is something I'm actively working towards.