Created attachment 465467 [details] a sample illustrating the issue For an item that is being dragged, as the drag proceeds, “drag” events are fired, and then, when the drag is complete, a “dragend” event is fired. In Safari Version 16.3 (18614.4.6.1.6) as well as Safari Technology Preview Release 165 (Safari 16.4, WebKit 18616.1.4.4), the coordinates in the “dragend” event are incorrect. They should roughly match the coordinates of the last move. To repro: 0. download the attached repro file (which logs the coordinates passed to the event listeners) 1. open the file 2. open the console for the page 3. drag the block of text on the page 4. stop the drag Expected: - The “dragend” event coordinates should roughly match the coordinates of the last “drag” event coordinates Actual: - The “dragend” event coordinates do not match the coordinates of the last “drag” event coordinates, and are very incorrect in relation to the client (e.g. if you drop near the upper left corner of the screen, the last “drag” event coordinates will be small and single-digit while the “dragend” coordinates will be in the 300-900 range) This is reproducible on my iMac Pro, with aforementioned Safari and STP, on macOS 13.2.1 (22D68).
<rdar://problem/107154521>
FYI: Chromium encountered a similar issue (https://crbug.com/1424292) when we moved from an old macOS API to a modern one. In the old version of the code, we used to use -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] which for the position took the corner of the image, and when -[NSDraggingSource draggedImage:endedAt:operation:] was called, the ending point was the corner of the image again. Therefore, in our old code, we had to offset the ending point to find the actual coordinates of the drag that we wanted. We modernized our use of the drag API (https://crrev.com/c/4114681), moving to -[NSView beginDraggingSessionWithItems:event:source:]. When the drag was over, that calls -[NSDraggingSource draggingSession:endedAtPoint:operation:]. There was no need to offset the ending point, as this new API gives the correct point, but we incorrectly kept our offsetting code. We solved (https://crrev.com/c/4347532) our version of this bug by removing this offsetting. I don’t know what the underlying cause of this bug is for you, but given the shared history of WebKit and Blink, it’s possible that when you moved to the new macOS drag API, you too didn’t realize you needed to remove this obsolete offsetting code. If that indeed turns out to be the case for you, I hope that our pain in discovering this helps make your bug fix easier.