1772073 - [KDE] Flash happens & Application menu popup moves briefly to the left when hovering over "List all tabs" and an extension buttons

Status: RESOLVED FIXED

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

Description

[Lyubomir [:mystiquewolf]]

Attachment: 2022-06-01 11-24-11.mkv

Haven't noticed it before, not sure if regression with Firefox 101.
Martin, i think this is potentially Gtk/Wayland bug, what logs/command outputs might help?

Comment 1

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

Yes, looks like Wayland issue. Please test latest nightly, it may be Bug 1771104 which is already fixed.
Thanks.

Comment 2

[Lyubomir [:mystiquewolf]]

Still happens in Nightly build 20220601213138

Comment 3

[Lyubomir [:mystiquewolf]]

I have a feeling these two might be related somehow: https://bugzilla.mozilla.org/show_bug.cgi?id=1768177#a515172_584718

Comment 4

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

Okay, Thanks. Please create a screencast and attach it here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.

Comment 5

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

Ah, I see you did that already, thanks.

Comment 6

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

Do I understand correctly that the flashing window is a tooltip which is supposed to be opened under the extension icon?

Comment 7

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

Also which distro/desktop do you run?

Comment 8

[Lyubomir [:mystiquewolf]]

Operating System: Arch Linux
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4

The flashing window as far as i can see that fast - is the application menu which moves for part of the second to the leftmost edge of the screen and then returns back.

Comment 9

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

Can you try mutter compositor?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
Thanks.

Comment 10

[Lyubomir [:mystiquewolf]]

Couldn't reproduce it in mutter, and it reproduces easily in KDE.

Is there really no way to start mutter window bigger than this small size? ¯(©¿©) /¯

Comment 11

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

Yes, you can use 'Running nested as a subcompositor' steps from
https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/Testing

Comment 12

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

Vlad, any idea here?
Thanks.

Comment 13

[Vlad Zahorodnii [:zzag]]

I've seen this bug report (open the context menu and hover any firefox ui element so a popup appears), but didn't dig into it. Will debug it.

Comment 14

[Vlad Zahorodnii [:zzag]]

Whenever a new popup is shown, the subsurface for context menu is destroyed and created again. Can firefox avoid doing that?

Comment 15

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

I think that comes from Gtk where we re-map the popup. Will look at it.

Comment 16

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

Vlad, I tested the most simple scenario:

1. open hamburger menu and keep it opened
2. move mouse cursor to some icon and keep Firefox to create tooltip over it
3. quit

and it's reproducible in 30% cases.

In such scenario no subsurface is deleted - we just create a popup (hamburger), create another popup (tooltip) and make it child of hamburger.
I don't see any subsurface manipulation/delete so it looks like KDE bug to me, especially when hamburger popup is misplaced but Firefox doesn't touch it.

(I use MOZ_LOG="WidgetWayland:5 WidgetPopup:5" env variable to print popup & wayland operations initiated by FF).

Comment 19

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

The subsurface delete comes from gdk_wayland_window_set_transient_for() - it unmaps the subsurface in case we use subsurface popup type.
While I can try to switch tooltips to XDG popup types, this code comes from Gtk3 and may be used by other applications.

Comment 20

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

Okay I think I understand it now. gdk_wayland_window_set_transient_for() does not check if previous parent is the same and deletes the subsurface even when nothing changes. So we need to call gdk_wayland_window_set_transient_for() of if there's a change to avoid the unmap.

Comment 21

[Vlad Zahorodnii [:zzag]]

Sounds like it can be fixed by adding an if statement \o/

Comment 22

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

Attachment: Bug 1772073 [Wayland] Call gtk_window_set_transient_for() only if widget parent is changed r?emilio

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/94a5a247f53c
[Wayland] Call gtk_window_set_transient_for() only if widget parent is changed r=emilio

Comment 24

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/94a5a247f53c