1993660 - [wayland][KDE] Holding down left mouse button while clicking hamburger menu button causes hover misalignment at top-left window area instead of inside popup

Status: RESOLVED MOVED

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

Description

[spitko]

Attachment: Screencast_20251009_235120.webm

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

Steps to reproduce:

On the back, forward of hamburger menu, hold down the button instead of clicking. When the menu appears, continue holding and move your mouse down.

Cachyos under KDE Plasma with Wayland. This is a dual monitor system with 150% display scaling. This also reproduces under TuxedoOS with the same configuration.

Actual results:

The mouse cursor will be in the wrong position, not interacting with any menu items but instead interacting with other interface elements on firefox. The offset seems to be a bit unpredictable, but biases towards the left side of the window. This continues until the mouse is released, where the cursor behaves normally again.

Expected results:

The selection should reflect the mouse cursor

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

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

Bug 1992198 may fix it.

Comment 3

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

Can you check if you see it with scale 100%?
Thanks.

Comment 4

[Kestrel]

I can reproduce this with 100% scale on a single display Kubuntu 25.04 live USB. Does not occur on Ubuntu 25.10 GNOME. Happens regardless of window maximized state or titlebar CSD. Happens with Wayland but not XWayland.

It has similarities to Bug 1987057 but has an older regression window.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=967ae1edad41790a5a1fde2f1591731784117c7a&tochange=3e93c8e836ff3fb0c0a953d6451adf188ada355f

Possibly regressed by Bug 1755323.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

From the regression range it seems like another subsurface vs. xdg_popup difference in kde.

Comment 6

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

Please run on terminal with 100% scale with MOZ_LOG="Widget:5 WidgetPopup:5" and attach the log here.
Is that reproducible on single monitor system with 100% scale?
Thanks.

Comment 7

[Vlad Zahorodnii [:zzag]]

This might be due to the implicit grab. When a pointer button is pressed, an implicit grab will be established, meaning that the focus won't change until the button is released. Maybe kwin needs to relax the implicit grab restrictions, I don't know what mutter does, maybe it allows the wl_pointer focus surface to change as long as surfaces are owned by the same client who received the button press event.

Comment 8

[BugBot [:suhaib / :marco]]

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

Comment 9

[Kestrel]

Attachment: MOZ_LOG="Widget:5,WidgetPopup:5"

Log captured on single monitor at 100% scale.

Comment 10

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

(In reply to Vlad Zahorodnii [:zzag] from comment #7)

This might be due to the implicit grab. When a pointer button is pressed, an implicit grab will be established, meaning that the focus won't change until the button is released. Maybe kwin needs to relax the implicit grab restrictions, I don't know what mutter does, maybe it allows the wl_pointer focus surface to change as long as surfaces are owned by the same client who received the button press event.

Vlad, may it be a difference between xdg_popups and subsurface based ones? Firefox switched from xdg_popups to subsurface ones if popup fits in Firefox toplevel window.

Kestrel, do you see the but if you make Firefox window smaller that hamburger popup so Firefox is forced to use xdg_popup ?
Thanks.

Comment 11

[spitko]

I can confirm shrinking the window so the hamburger menu no longer fits does indeed "fix" the problem, so your theory is likely correct.

Comment 12

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

Okay, looks like KDE bug then.

Comment 13

[Vlad Zahorodnii [:zzag]]

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

(In reply to Vlad Zahorodnii [:zzag] from comment #7)

This might be due to the implicit grab. When a pointer button is pressed, an implicit grab will be established, meaning that the focus won't change until the button is released. Maybe kwin needs to relax the implicit grab restrictions, I don't know what mutter does, maybe it allows the wl_pointer focus surface to change as long as surfaces are owned by the same client who received the button press event.

Vlad, may it be a difference between xdg_popups and subsurface based ones? Firefox switched from xdg_popups to subsurface ones if popup fits in Firefox toplevel window.

Kestrel, do you see the but if you make Firefox window smaller that hamburger popup so Firefox is forced to use xdg_popup ?
Thanks.

Too late, but yeah kwin will allow focused surface to be changed if it's a subsurface.

Upstream bug report https://bugs.kde.org/show_bug.cgi?id=477740