2005452 - [KDE/Wayland] Nested folders drop down in wrong position on scaled monitor

Status: UNCONFIRMED

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

Description

[madness742]

Attachment: bookmarks_position_wrong.png

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

Steps to reproduce:

(This bug can also be reproduced on Nightly 147.0a1 - 2025-12-07)

Monitor setup:

• Primary monitor (2560x1440, 100% scaling).
• Secondary monitor (2160x3840, 150% scaling).

1. Create a folder in Bookmarks Toolbar.
2. Create another folder, within the newly created folder.
3. Populate that folder with a couple bookmarks.
4. Move Firefox to the second monitor. (150% scaling)
5. Open the nested folder.

Actual results:

The position of the drop down menu is in the wrong position, when following the steps on the scaled monitor.

Expected results:

It should behave like the non-scaled monitor.

Comment 1

[BugBot [:suhaib / :marco]]

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

[Thinker Li [:sinker]]

Please check bug 2005152. Is it what happened to you?

Comment 3

[madness742]

It does seem related, but he's encountering it on a single monitor with 100% scaling. I can only reproduce this issue on a scaled monitor. I also don't need to nest the folders as much as him for this bug to occur.

The drop down menu also isn't out of the screen, unless I don't maximize Firefox.

Under about:support, my secondary monitor reports the wrong resolution and scaling.

Display0 2880x5120@60Hz scales:2.000000|2.000000 <-- Secondary monitor
Display1 2560x1440@144Hz scales:1.000000|1.000000 <-- Primary monitor

Comment 4

[madness742]

Attachment: kde_monitor_output.png

Comment 5

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

Can you please create a screen cast of it?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Create_screenshot/screencast_for_a_bug_report
Thanks.

Comment 6

[madness742]

Attachment: Video showcase of the issue.

Comment 7

[Thinker Li [:sinker]]

Do you ever try to switch the arrangement of two screens (left<->right)?

Comment 8

[Thinker Li [:sinker]]

Could you provide the log generated by firefox with the following command?

env MOZ_LOG="timestamp,WidgetPopup:5" MOZ_LOG_FILE="popup" firefox

Attach the file popup.moz_log there.
Please keep the test as short as possible, just enough to reproduce the issue.

Comment 9

[madness742]

(In reply to Thinker Li [:sinker] from comment #7)

Do you ever try to switch the arrangement of two screens (left<->right)?

It makes no difference if I place the left monitor, right of the primary monitor.

(In reply to Thinker Li [:sinker] from comment #8)

Could you provide the log generated by firefox with the following command?

I'll attach the log file, but I wasn't able to get it working on the Flatpak build. So instead I used Nightly 148.0a1 (2025-12-13).

Comment 10

[madness742]

Attachment: popup.moz_log

The window initially started on my primary monitor. I moved it to the second monitor, clicked on "Other Bookmarks", selected the first bookmark folder (correct position), moved the cursor to the second bookmark folder (bugged position), hit escape twice in a row and closed Firefox.

Comment 11

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

That depeneds on compositor how is the window placed. It's not managed by Firefox itself. I suggest to file a bug against KDE/Kwin.

Comment 12

[madness742]

I've reported it on the KDE bug tracker: https://bugs.kde.org/show_bug.cgi?id=513398

Comment 13

[madness742]

The KDE developers are saying that there's no bug on their side, and I've confirmed this by being able to reproduce it on Fedora 43 Workstation (GNOME 49).

Comment 14

[Thinker Li [:sinker]]

In the log provided by comment #10, the menu of the second bookmark folder is placed at the right side of the folder item at beginning and moved to a buggy position immediately. Checking the video in comment #6, you can see the buggy menus are placed at the left of the item (not right), then move to a buggy position. It matches what I observed in the log. So, that means Firefox made the movement.

I think it is the compositor placing menu at the left of the item, not right. I guess the reason placing at left is that Firefox place the menu out of the visible area (according to the log) of the screen and the compositor adjust it position according to the anchor rect and the gravity.

nsWindow::Resize [1450.67,196.00] -> [537.33 x 452.00] scaled [1451,196] -> [537 x 452] repaint 1

If I am right, the size of the logic screen of Wayland is 1440 x 2560. [1450.67,1960.00] above is invisible.

Somehow, 20~40ms later, it moves the menu left to a buggy position twice. At this moment, the menu is visible, and the compositor doesn't adjust it's position.

nsWindow::Move to [784 x 196] scale 1.500000 scaled [1176.00 x 294.00]
nsWindow::Move to [915 x 199] scale 1.500000 scaled [1372.50 x 298.50]

In the video of comment #6, KDE also has some weird behavior. For example, sometime it allow to extend the menu to the right screen (primary screen), but sometime it doesn't allow.

Other evidences are log messages of layout popup CSS anchor. They show the CSS of the popup frame has been changed 4 times for reasons unknown yet.

I guess always placing menus in visible positions of the current screen can avoid this unpredictable behavior.

Comment 15

[Thinker Li [:sinker]]

Thank you for the log in the comment #10!

Could you capture your desktop and the log while doing test?
I would like to match the positions in the log match what is on the screen.

Please use the following command. Thanks!

env MOZ_LOG="timestamp,WidgetPopup:5,WidgetScreen:5" MOZ_LOG_FILE="popup" firefox

Comment 16

[madness742]

I had to downgrade my Nightly version to 2025-12-13-09-12-41 in order to reproduce the problem.

In Nightly 2025-12-17, nested folders with bookmarks appear in the correct position, but not empty nested folders on the scaled monitor.

There's also a slight blur when opening "Other Bookmarks" on the scaled monitor, and after one second it looks sharp. This can also be seen in the context menu when right clicking on a page, or when hovering over a different nested folder. These blur issues are not present on the primary (non-scaled) monitor. Changing scaling on the primary monitor for 100% to 150% makes me able to reproduce the blur issue.

Comment 17

[madness742]

Attachment: video_popup.mkv

Comment 18

[madness742]

Attachment: video_popup.moz_log

Comment 19

[Thinker Li [:sinker]]

In Nightly 2025-12-17, nested folders with bookmarks appear in the correct position, but not empty nested folders on the scaled monitor. Do you mean empty nested folders are still buggy? Or not?

Comment 20

[madness742]

The empty nested folders are still buggy, I'll attach a video of the problem.

Comment 21

[madness742]

Attachment: Behaviour on Nightly 2025-12-17.mkv

Comment 22

[Thinker Li [:sinker]]

Summary of my investigation.

When a menu is out of the visible region of the screen, the compositor moves it to the other side of the parent menu from right to left. It causes side-effects. A "move-to-rect" callback NativeMoveResizeCallback() is called. The callback eventually calls nsMenuPopupFrame::MoveTo(). The following is some facts of nsMenuPopupFrame.

• The value of mAnchorType is MenuPopupAnchorType::Node at beginning
• MoveTo() changes the value of mAnchorType to MenuPopupAnchorType::Point if mAnchorType is not MenuPopupAnchorType::Rect when enter the function.
• MoveTo() moves mScreenRect to the top-left of the current nsMenuPopupFrame.
• MoveTo() calls GetRects() indirectly through SetPopupPosition(), and GetRects() compute the value of nsMenuPopupFrame::mUntransformedAnchorRect (keeping in result.mUntransformedAnchorRect for temporary). It's value will be at the top-left corner of menu popup before moving the position if mAnchorType is MenuPopupAnchorType::Point (IsAnchored()).
• mUntransformedAnchorRect is passed to gdk_window_move_to_rect(). The compositor will make sure the popup is overlaid with the rect.
• MoveTo() eventually call gdk_window_move_to_rect() to move the popup to the position given by the compositor although it is not necessary since the compositor had moved it.

The problem is the compositor moves the menu popup to left side of the parent popup. However, the rect mUnstransformedAnchorRect passed to gdk_window_move_to_rect() is at the top-left corner of the popup before moving it. It is at the right side of the parent menu. That means the new position of the menu popup is not overlaid with the rect. So, the compositor will try to move the popup again to make sure the popup cover the rect. It is the buggy position over the parent menu like what we see in the video.

Keeping mUntranformedAnchorRect untouched for this case may fix the issue.

Comment 23

[Emilio Cobos Álvarez [:emilio]]

So when we MoveTo() it's expected to change the anchor rect. I think what's going on is that on the scaled monitor we're incorrectly drifting away because of rounding. I think bug 2003258 fixes this, can you confirm latest nightly doesn't show the issue?

Comment 24

[madness742]

When I open Firefox, and move it to the second monitor, the nested empty folder get shown on my main monitor. This does not happen with nested folders that contain bookmarks.

If I maximize Firefox on the scaled monitor and open the empty nested folder, it will show up correctly when Firefox isn't maximized.

Comment 25

[madness742]

Attachment: Behaviour_on_2025_12_21.mkv