1761877 - [wayland][xwayland] Cannot drag bookmarks out of folders or overflow menu in toolbar

Status: RESOLVED FIXED

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

Description

[gliu20]

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

Comment 1

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

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.

Comment 2

[gliu20]

I'm pretty sure this belongs under bookmarks & history

Comment 3

[Martin Stránský [:stransky] (ni? me)]

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

Comment 4

[gliu20]

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

Comment 6

[Martin Stránský [:stransky] (ni? me)]

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

Comment 7

[gliu20]

Attachment: Screencast from 2022-05-03 04:29:04 PM.webm

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Thanks!

Comment 9

[Kestrel]

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.

Comment 10

[Kestrel]

Attachment: Video of dragging outside bookmark folder getting stuck on XWayland

Comment 11

[Kestrel]

Attachment: Video of dragging outside bookmark folder getting cancelled on Wayland

Comment 12

[Martin Stránský [:stransky] (ni? me)]

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

Comment 13

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

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

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Attachment: Screencast from 10-14-2022 11:14:58 AM.webm

Comment 16

[Martin Stránský [:stransky] (ni? me)]

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?

Comment 17

[Martin Stránský [:stransky] (ni? me)]

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?

Comment 18

[Martin Stránský [:stransky] (ni? me)]

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

Comment 19

[Martin Stránský [:stransky] (ni? me)]

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?

Comment 20

[Martin Stránský [:stransky] (ni? me)]

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

Comment 21

[Emilio Cobos Álvarez (:emilio)]

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)

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Thanks, I think I'm on track.

Comment 23

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 24

[Martin Stránský [:stransky] (ni? me)]

We also need to use that on XWayland too.

Comment 25

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1761877 [Linux] Add isWaylandDragSource and isWaylandPopup attributes to XULPopupElement r?emilio

Comment 26

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1761877 [Linux] Don't close bookmarks popup if it's a source of Drag&Drop r?emilio

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

Depends on D161127

Comment 27

[Martin Stránský [:stransky] (ni? me)]

More background info according to Wayland protocol:
https://www.mail-archive.com/[e-mail]/msg41784.html

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3a8608560898
[Linux] Add isWaylandDragSource and isWaylandPopup attributes to XULPopupElement r=emilio
https://hg.mozilla.org/integration/autoland/rev/2d88e30472c7
[Linux] Don't close bookmarks popup if it's a source of Drag&Drop r=emilio,mak

Comment 29

[Cristian Tuns]

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