2003045 - [Ubuntu 24.04LTS GNOME 46] Misplaced popups (Dev Tools Console Settings, context-menu) sometimes appear at top-left window corner

Status: RESOLVED FIXED

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

Description

[erosman [:erosman]]

Subsequent to bug 1999123, there are other instances of misplaced popups. e.g. the Dev Tools Console Settings popup and the context-menu popup.

STR

• Open the Dev Tools (F12)
• Go to the Console Tab
• Click on the cogwheel icon (top right)

AFA the context-menu, it is sporadic. I noticed it when right-clicking links, images but there is no definite pattern for STR.

Note: the Dev Tools Settings popup misplacement only happens when Firefox is maximised.

Ubuntu 24.04 Wayland
Nightly

Comment 1

[erosman [:erosman]]

Attachment: bug2003045-a.png

Comment 2

[erosman [:erosman]]

Attachment: bug2003045-b.png

Comment 3

[erosman [:erosman]]

Attachment: bug2003045-c.png

Dev Tools -> Inspector -> mouse-over item with a popup (e.g. var(--step-3))

Comment 4

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Not sure I can reproduce on Gnome 49. The cogwheel icon popup uses negative margin so we position it wrongly with move-to-rect but I don't see the 0,0 position but rather x-200 one.

Can you try to get MOZ_LOG="Widget:5 WidgetPopup:5" ./firefox > log.txt 2>&1 log for any of the misplaced popups?
Thanks.

Comment 5

[erosman [:erosman]]

Can you try to get MOZ_LOG="Widget:5 WidgetPopup:5" ./firefox > log.txt 2>&1 log for any of the misplaced popups?

I have done this before and I did it again, but all I get in the log is:

[18579] Sandbox: CanCreateUserNamespace() unshare(CLONE_NEWPID): EPERM

Note: the Dev Tools Settings popup misplacement only happens when Firefox is maximised.

Comment 6

[erosman [:erosman]]

Attachment: bug2003045-d.png

Also in: Firefox 145.0.2 build ID 20251125000153, maximised

Comment 7

[erosman [:erosman]]

Attachment: bug2003045-e.png

Firefox 145.0.2 build ID 20251125000153, not-maximised

Comment 8

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I suspect it's due to negative margin - will check it.

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I see the same bug on 145.0.2.

Comment 10

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Looks like it's due to flip_x used there:

[Parent 86908: Main Thread]: D/WidgetPopup [7f0385d0ad00]:   Anchor rect [1712, 655] -> [1 x 1]
...
[Parent 86908: Main Thread]: D/WidgetPopup [7f0385d0ad00] NativeMoveResizeCallback flipped_x 1 flipped_y 0
[Parent 86908: Main Thread]: D/WidgetPopup [7f0385d0ad00]    new position [1474, 646] -> [228 x 176]

Comment 11

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I wonder if we can check the popup type and disable flip if popup has the visible anchor. Emilio, do you know if we can check that?
Thanks.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Well, yes, and no. Doing that would be counter-productive for most other popups, right? Even if the anchor is visible the popup might not (think putting an extension window at the left of the toolbar).

The main issue is that these DevTools popups don't use the usual <menupopup> styling so we believe the shadow is part of the popup's content that may be visible...

But also the position shouldn't end up at 0,0? I can't reproduce this on KDE...

Comment 13

[Kestrel]

The displaced devtools popups when overflowing is already covered by Bug 1823249.

The (0,0) popup placement is a new regression that affects Ubuntu 24.04LTS (GNOME 46) but not Ubuntu 25.10 (GNOME 49) (single display).
At 100%, 175% and 200% scale, overflowing devtool popups consistently appear at (0,0).
At 125% and 150% scale, popups only flash briefly at (0,0) before correcting.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f84254926bdf6d2506f6577156f9e7804fc9de38&tochange=cd20a71d574690e3162d9368225defce3ff06969

Regressed by Bug 1998382.

Comment 14

[Kestrel]

Attachment: Devtools popup on Ubuntu 24.04LTS at 100% scale

Comment 15

[Kestrel]

Attachment: MOZ_LOG="Widget:5 WidgetPopup:5" at 100% scale

Comment 16

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Kestrel, can you please run the case when popup is placed at 0,0 persistently with MOZ_LOG="Widget:5,WidgetPopup:5" WAYLAND_DEBUG=1 variables and attach the log here?

From the widget log only it looks like we place the popup correctly (somehow) according to what compositor gives us.

Comment 17

[Kestrel]

Attachment: WAYLAND_DEBUG=1 MOZ_LOG="Widget:5,WidgetPopup:5" at 100% scale

Comment 18

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

Set release status flags based on info from the regressing bug 1998382

Comment 19

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

If that's Gnome 46 compositor bug (perhaps wrong interaction between xdg-popup and persistent wl_surface) which leads to persistent 0,0 popup placement we can detect such case and use plain move to original coordinates (direct placement) or place the popup inside of toplevel window.

Comment 20

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Hm, is the log really for the popup shown at 0,0? Because the says it's shown at 1408, 706:

[2041279.057] [e-mail](1408, 706, 233, 173)
[Parent 208245: Main Thread]: D/WidgetPopup [7c6f3a019600] NativeMoveResizeCallback flipped_x 1 flipped_y 1
[Parent 208245: Main Thread]: D/WidgetPopup [7c6f3a019600]    new position [1408, 706] -> [233 x 173]
[2041279.119] [e-mail](6751)

so compositor says it's displayed at [1408, 706] but actually rendered at 0,0. If that's already fixed in Gnome 49 we shall ask Ubuntu to backport the compositor fix to Mutter 46 then.

Comment 21

[Kestrel]

Attachment: Flipped context menu renders at (0,0) but interactive at original location

Easily encountered by right-clicking near bottom screen edge where the context menu flips above the cursor. Despite the menu appearing at (0,0), it is still interactive in its original expected location. Submenus appear in their correct location.

The black box in the recording is transparent and has a hall of mirrors effect when the cursor passes over it.

Comment 22

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I think widget.wayland.use-move-to-rect set to false fixes it, right?
Thanks.

Comment 23

[Kestrel]

It does not happen with widget.wayland.use-move-to-rect = false.

Comment 24

[Petruta Horea [:phorea]]

Attachment: vertical tab preview

Reproduced when hovering the bottom tabs when they are vertical and overflow. Mozregression pointed out to bug 1998382.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Hi Martin, what's our path forward on this bug?

Comment 26

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Will check that on actual Ubuntu 24.04LTS. We have only this report so doesn't look much wide-spread? Or may be affect only specific line?
Anyway, the best solution is to persuade ubuntu folks to update mutter to fixed/working version. Or we can use widget.wayland.use-move-to-rect=false there (with some plumbing & boundaries updates) but there's a problem to detect the environment correctly - can we check we're running Ubuntu 24.04LTS?

Comment 27

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Okay, testes on Ubuntu 24.04LTS. From the testing it looks like when wl_surface is created & used with xdg_popup and then the save surface is used with wl_subsurface we see the misplacement here.

So if we use xdg_popup with popup we need to keep that method and don't switch to subsurfaces for it.
So this is a generally a regression from Bug 1975969 revealed by Bug 1998382 (but still Mutter 46 only bug).

Comment 28

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

I think we just need to keep mPopupUseMoveToRect true if that's set once.

Comment 29

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

We may also add alway-use-move-to-rect option for testing such cases.

Comment 30

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Attachment: Bug 2003045 [Wayland] Don't switch between xdg_popup and wl_subsurface popups r?emilio

Comment 31

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

We should backport it to beta.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b96c90b108ae
https://hg.mozilla.org/integration/autoland/rev/183ace6d9d02
[Wayland] Don't switch between xdg_popup and wl_subsurface popups r=emilio

Comment 33

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/183ace6d9d02

Comment 34

[Donal Meehan [:dmeehan]]

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

We should backport it to beta.

Please add a beta uplift request when ready.
It might be too late for release, but please consider adding a request just in case.

Comment 36

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Comment on attachment 9539731 [details]
Bug 2003045 [Wayland] Don't switch between xdg_popup and wl_subsurface popups r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: popup windows may be misplaced on Wayland
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Disable popup placement optimization we introduced in Bug 1975969.
• String changes made/needed:
• Is Android affected?: No

Comment 38

[Donal Meehan [:dmeehan]]

Comment on attachment 9539731 [details]
Bug 2003045 [Wayland] Don't switch between xdg_popup and wl_subsurface popups r?emilio

Approved for 148.0b8

Comment 39

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f213ca5091c8
https://hg.mozilla.org/releases/mozilla-beta/rev/27044183a2a5

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9539731 [details]
Bug 2003045 [Wayland] Don't switch between xdg_popup and wl_subsurface popups r?emilio

Approved for 147.0.3

Comment 42

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/35f1c1a3e287
https://hg.mozilla.org/releases/mozilla-release/rev/73bf803d2339

Comment 43

[Petruta Horea [:phorea]]

Attachment: 147.0.3 wayland popups.mp4

I could still reproduce the issue with Firefox 147.0.3, 148 beta 10 and latest Nightly 149.0a1 2026-02-02 under Ubuntu 24 Wayland.

All the issues mentioned in this bug and in the duplicates (context menu position, tab hover preview, developer tools, console settings) are still reproducible.
It might not occur as often, but once hit, the wrong popup position will persist longer and for several trigger points.

Example: the tab hover preview that I pointed out in comment 24 was only shown for the bottom tabs (2 or 3). Now, once hit, the preview will be shown in top left corner for all the tabs (please see the attached video).

Comment 44

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

(In reply to Petruta Horea [:phorea] from comment #43)

Created attachment 9542300 [details]
147.0.3 wayland popups.mp4

I could still reproduce the issue with Firefox 147.0.3, 148 beta 10 and latest Nightly 149.0a1 2026-02-02 under Ubuntu 24 Wayland.

All the issues mentioned in this bug and in the duplicates (context menu position, tab hover preview, developer tools, console settings) are still reproducible.
It might not occur as often, but once hit, the wrong popup position will persist longer and for several trigger points.

Example: the tab hover preview that I pointed out in comment 24 was only shown for the bottom tabs (2 or 3). Now, once hit, the preview will be shown in top left corner for all the tabs (please see the attached video).

Please file a new bug for it. Do you have any exact reproduction steps?
Thanks.

Comment 45

[Petruta Horea [:phorea]]

Thank you! I filled bug 2014419.
There are no exact reproduction steps, I just clicked around to see if the issue was fixed and I encountered it again pretty easily, with both new or used Firefox profiles.