fix: detect delete areas using pointer coordinates#10078
Conversation
| * @returns Null if not over a drag target, or the drag target the event is | ||
| * over. | ||
| */ | ||
| getDragTarget(e: PointerEvent | Coordinate): IDragTarget | null { |
There was a problem hiding this comment.
Here especially, and kinda throughout, I think this really should have always taken a coordinate; I'd suggest leaving it as-is. Also this is technically breaking. In general I think only the actual event listener should handle events, and any methods called by it or its callees should take specific/abstracted arguments, rather than handing events around all over the place and picking one or two properties out of them.
| return; | ||
| } | ||
|
|
||
| let wouldDelete = false; |
There was a problem hiding this comment.
Why was this moved back here and made a let? It seems like it's still only assigned in one place and read right after that down below?
| x: (bounds.left + bounds.right) / 2, | ||
| y: (bounds.top + bounds.bottom) / 2, |
There was a problem hiding this comment.
This only maths if it's at (0,0) right? and same for rectCenterClient below
2 participants
The basics
The details
Resolves
Fixes #10077
Proposed Changes
Dragger: Delete-area detection during pointer drags now uses the cursor position (PointerEvent.clientX/clientY) instead of the block’s workspace origin (getRelativeToSurfaceXY()). Block movement is unchanged; only hit testing for delete styling, drag-target hooks, and drop/delete ononDragEndfollow the pointer.WorkspaceSvg.getDragTarget: Accepts onlyPointerEventonce again.onDragskips delete-area logic when the event is not aPointerEvent;onDragEndcommits without delete-area checks.This effectively reverts one particular change introduced by #9593
Reason for Changes
Previously, deletion could trigger when the block origin overlapped a delete area even if the cursor was elsewhere, for example, dragging a block over the workspace while its top-left corner still intersected the toolbox column. Now, deletion depends on where the user is pointing, not where the block’s origin happens to be.
This conveniently seems to resolve #10076 as well, likely due to
getRelativeToWorkspaceXY()returning the wrong sort of coordinates for zoomed workspaces. (I did not bother to root cause this, but did confirm it's no longer happening.)Test Coverage
New mocha suite simulating realistic drags with delete areas.
onDragEnd.