User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

1. Open latest Firefox Nightly
2. Show bookmark toolbar
3. Create a bunch of bookmarks on the toolbar until you have multiple bookmarks in the overflow menu
4. Drag a bookmark out of the overflow menu onto the toolbar

Actual results:

We escape out of bookmark dragging mode so it is impossible to move bookmarks

Expected results:

Bookmark should be dropped onto the toolbar

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I'm pretty sure this belongs under bookmarks & history

That may be Wayland specific issue. Please run nightly on terminal with MOZ_ENABLE_WAYLAND=0 env variable and retest.
Thanks.

Yeah I can confirm it appears to be Wayland-specifc. It doesn't repro when MOZ_ENABLE_WAYLAND=0 is set.

Can you create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.

Thanks!

The same occurs for folders in the bookmarks toolbar, when trying to drag items outside the popup, it closes and the drag operation gets cancelled.

Wayland: Drag operation stops when popup closes.
XWayland: Drag operation get stuck when popup closes, item cannot be moved and operation needs to be cancelled.
X11: Drag operation continues after popup closes.

Looks like when the source (popup) window is closed the D&D is canceled.

Yes, we need to source popup opened to keep the D&D running. The popup is closed by browser / js code. Emilio, any idea where to look to disable the source D&D popup close?
Thanks.

It's closed from a timer here: https://searchfox.org/mozilla-central/rev/ffa4d00965c5281def6d3ddcbcdf6259d38c9b9a/browser/components/places/content/places-menupopup.js#140-151

Comment on attachment 9298592 [details]
Screencast from 10-14-2022 11:14:58 AM.webm

Thanks Emilio, that fixes half of the cases here. We need another fix to keep opened leaf popup if it's source of D&D. I guess that close comes from common menu handlers - any idea where should look at?

I think we should generally block any close attempt if a popup is source of D&D action on Wayland. I wonder what happens if we ignore close/hide request from layout - may that cause any trouble? Is such popup marked as closed by layout or does layout query actual popup state from widget code?

We need to handle it on JS/layout level. Fiddle with popup visibility on widget level brings many issues here.

I think the best way how to fix that is add 'is_drag_source' attribute to the popup element at JS level and don't close such popup. I see the popup is MozElements type. Emilio, any hint how to add it there? I already have such attribute ready as a member of nsWindow. So we may export it by nsIWidget, but how to get that from/by popup?

Looks like we may add it to https://searchfox.org/mozilla-central/source/dom/webidl/XULPopupElement.webidl

Yeah, that seems sensible off-hand. Do you still need me to look at where the popup is closed? FWIW the thing I tend to do is just put a DumpJSStack() call in here (or a printf + rr for native code)

Thanks, I think I'm on track.

From all the tests I did I think the best variant is to keep the popup opened on widget/gtk level. It's difficult to keep the popup opened on JS level as it needs various hacks spread in the code and I didn't manage to do that properly anyway.

We also need to use that on XWayland too.

On Wayland Drag&Drop is canceled by compositor if source window is closed so keep it open.

Depends on D161127

More background info according to Wayland protocol:
https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg41784.html

https://hg.mozilla.org/mozilla-central/rev/3a8608560898
https://hg.mozilla.org/mozilla-central/rev/2d88e30472c7