1917562 - Drop marker remains after cancelling drag and drop into tabs or bookmarks

Status: NEW

(Core :: Widget: Gtk, defect, P3)

Description

[Kestrel]

Attachment: Cancelling drag leaves behind drop marker

STR:

1. Drag a link into the tab bar or bookmarks sidebar so that the drop marker appears on Ubuntu 24.04.
2. Press the Esc key to cancel the drag.

Expected:
Drop marker disappears.

Actual:
Drop marker remains until next drag and drop.

Happens with Wayland, XWayland and X11. Does not happen on Windows 11.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9ac7f1f672d585d3a66062be012715bfafbb1e4d&tochange=01bfc9faa69043308206f123a4f171b426aa2758

Regressed by Bug 1893119.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:handyman, since you are the author of the regressor, bug 1893119, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[David Parks [:handyman]]

[Parent 10770: Main Thread]: D/WidgetDrag invisibleSourceDragFailed(7c5ae5dbad40) GTK_DRAG_RESULT_NO_TARGET
[Parent 10770: Main Thread]: D/WidgetDrag [D 0] SourceEndDragSession(7c5ae5dbad40) result GTK_DRAG_RESULT_NO_TARGET
[Parent 10770: Main Thread]: D/WidgetDrag [D 0]   guess drag end point 562 46
[Parent 10770: Main Thread]: D/WidgetDrag [D 0]   drop action is none
[Parent 10770: Main Thread]: D/WidgetDrag [D 0] nsDragSession::Schedule(0) task eDragTaskSourceEnd window 7c5b19f85400
[Parent 10770: Main Thread]: D/WidgetDrag invisibleSourceDragEnd(7c5ae5dbad40)
[Parent 10770: Main Thread]: D/WidgetDrag [D 0] SourceEndDragSession(7c5ae5dbad40) result GTK_DRAG_RESULT_SUCCESS
[Parent 10770: Main Thread]: D/WidgetDrag [D 1] nsDragSession::RunScheduledTask() task eDragTaskSourceEnd mTargetWindow 7c5b19f85400 mPendingWindow 7c5b19f85400
[Parent 10770: Main Thread]: D/WidgetDrag [D 1]   quit, selected task eDragTaskSourceEnd
[Parent 10770: Main Thread]: D/WidgetDrag [D 1] nsDragSession::EndDragSessionImpl(0) 1
[Parent 10770: Main Thread]: D/WidgetDrag WindowDragLeaveHandler()
[Parent 10770: Main Thread]: D/WidgetDrag     Received dragleave after drag had ended.

The log snippet shows that the cancel inspires sending the drag-failed, handled by invisibleSourceDragFailed, and incorrectly concludes that the event is not a cancelled drag, setting the result to GTK_DRAG_RESULT_NO_TARGET. We then get no indication that the user cancelled the event (mUserCancelled == false) and SourceEndDragSession has no way to know to issue a dragleave first. Wayland sends a drag leave later, which is handled by WindowDragLeaveHandler. Up to this point, behavior is as pre-bug 1893119. However, WindowDragLeaveHandler (post-1893119) tries to use "the current" drag session to send the drag leave, but the drag session was already ended so it can't be used. IIUC, pre-1893119 we didn't need the drag session -- we sent the event anyway, which is technically ok but is a bit strange because the dragleave is sent after the dragend. I think this has been an annoyance for things like tab dragging. Restoring this approach might be the quickest solution.

Fundamentally, the problem seems to be that we can't ID a cancelled drag in invisibleSourceDragFailed (at least not in my experiments on Wayland, although the bug is reported for X11 as well). We need to know the difference because a non-canceled tab-drag is a tab-tear, but a canceled tab-drag is nothing. If we could properly set mUserCancelled then we could just use that to send the drag leave before the drag end in SourceEndDragSession (it already does that for some cases). FWIW, the new Wayland API recently implemented here is explicitly for this purpose and might help.