1866770 - [KDE] KWin/Wayland: It's not possible to drag&drop bookmarks into subfolders

Status: UNCONFIRMED

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

Description

[tgn-ff]

Attachment: bookmarks2.png

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

Steps to reproduce:

On KWin/Wayland.

0.Make sure you have a bookmark folder a few levels deep.

1. Try to move a bookmark to a subfolder.

Actual results:

The menu closes making it impossible to d&d the bookmark to the intended subfolder.

See the picture (I can't capture the screen on Wayland). I have two profiles that close at a different level; I'm not sure why. In one, the menu closes when the cursor moves from the menu of "Folder" to the menu of "Subfolder1", and the other when moving from "Subfolder1" to "Subfolder1,1".

This is not Bug 419911, I moved the cursor carefully between the submenus.

Expected results:

This is not a recent regression, so I can't find the exact commit that introduced it. Guessing from the mozregression result, the culprit is probably Bug 1750102, so I'll, tentatively, mark it as the regressor.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c3cfc0310a9cbaf8ba01594332b14e926976def6&tochange=490469b53dbe1ca42584dade11bcd1b4e573fe7a

Comment 1

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

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

For more information, please visit BugBot documentation.

Comment 2

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

This is a long standing bug and we don't have a perfect fix for it. Please try Gnome if it behaves better.
Thanks.

Comment 3

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

Also can you create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
To make sure we both mean the same behavior.
Thanks.

Comment 4

[tgn-ff]

Attachment: bookmarks.mp4

Comment 5

[tgn-ff]

Attachment: glxinfo.txt

Comment 6

[tgn-ff]

Attachment: eglinfo.txt

Comment 7

[tgn-ff]

Attachment: about_support.txt

Comment 8

[tgn-ff]

Attachment: vainfo_??.txt

Comment 9

[tgn-ff]

Gnome is not affected, and KWin is only affected on Wayland. I haven't tested other DEs/WMs.

Comment 10

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

I see, Thanks. Looks like KWin sends leave event so the popup is closed. We've landed series of patches for D&D on bookmarks but that was not tested on KDE. Added to KDE and D&D tracker for further fix.

Comment 11

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

Hm, I tested that on Fedora 39 / KDE and it works as expected. I use kwin-wayland-5.27.10. Which version do you run?

Comment 12

[tgn-ff]

Same version on archlinux. I still can reproduce it.

Comment 13

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

Interesting. Can you please try latest nightly under Wayland?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 14

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

I see that with Firefox 121 / default profile now but I don't see it with latest nightly + clean profile. I wonder if it's related to theming or so.

Comment 15

[tgn-ff]

It was Nightly I tested before; still reproducible.

I, too, see some variation between profiles. In one profile I can go one level in, in another one two levels in. I can reproduce it in clean profiles, although not as consistently.

Comment 16

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

Okay. Please run on terminal with MOZ_LOG="Widget:5 WidgetPopup:5" env variable, reproduce it once and attach the log here. like:

MOZ_LOG="Widget:5 WidgetPopup:5" firefox > log.txt 2>&1

and attach log.txt here.
Thanks!

Comment 17

[tgn-ff]

Attachment: oldprofile-Widget_5_WidgetPopup_5.txt

I'm attaching the logs from both an old and a new profile.

Comment 18

[tgn-ff]

Attachment: newprofile-Widget_5_WidgetPopup_5.txt

Comment 19

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

Thanks. Can you try to set browser.chrome.toolbar_tips to false at about:config and restart browser and retest?

Comment 20

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

(In reply to Martin Stránský [:stransky] (ni? me) from comment #19)

Thanks. Can you try to set browser.chrome.toolbar_tips to false at about:config and restart browser and retest?

Sorry, I mean ui.popup.disable_autohide pref. That's the one which controls rollups.
Thanks.

Comment 21

[tgn-ff]

Still reproducible with ui.popup.disable_autohide=true.

Comment 22

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

I don't see anything wrong in the log...I wonder if frame popup manager closes the popup from some reason we don't see. My guess it that we see Bug 419911 but we have wrong popup offsets (perhaps caused by CSD popup decorations?) so frame manager has wrong coordinates and thinks we're out of the window.

Comment 23

[tgn-ff]

Attachment: bookmarks-test.html

I tried to create a folder structure that would reproduce the issue always when created in new profiles, since it seems it's somewhat depended on it. I was able to reproduce the issue reliably by importing the attached file (exported bookmarks to HTML) to new profiles.

Comment 24

[tgn-ff]

Some notes before I forget them.

1. This seems to be highly depended on the size of the width of the menu, or in other words a) on the bookmark/folder names and b) the font in use. It will happen no matter what, but depending on those you might be able to reach a few more levels deep into the subfolders.

2. In new versions (of KDE) the cursor visually changes to the "not-allowed" icon between the menus before they close.

3. Setting widget.wayland.use-move-to-rect to false allows the menus to stay open and you can drag the bookmark along. The menus can go outside screen boundaries when turning off this pref, of course, so this isn't a workaround.

Comment 25

[luniac]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #22)

I don't see anything wrong in the log...I wonder if frame popup manager closes the popup from some reason we don't see. My guess it that we see Bug 419911 but we have wrong popup offsets (perhaps caused by CSD popup decorations?) so frame manager has wrong coordinates and thinks we're out of the window.

I have the same issue. Is there any extra debugging information that may be helpful?

Comment 26

[tgn-ff]

It should be noted, that Bug 1975969 made the issue a little better, thus making reproducing the bug a little harder, but it's still here.