Broken multi-level popup menu in Wayland after upgrading to Qt 6.5.1

[taoky]

Steps to reproduce

1. Right click on channels, groups or contacts in the left panel.
2. Move mouse to "Mute notifications" in the popup menu, and then move mouse to other places without clicking.

Flathub org.telegram.desktop 9e5fbec1a065f8a7475d5634aa2a67b176535303fa44a7379504d5893617370f is the latest version that does not have this bug. Also, telegram-desktop distributed by Arch also has this issue, thus it looks possibly a regression in Qt 6.5.1.

Screen record in flathub 81b809fd4902584f0cc9cab6173cba220d1b51e11c1307b61b5fa58c6a85c8c2 (4.8.1), with nested weston:

Kooha-2023-06-14-17-43-18.mp4

Expected behaviour

The menu still stays in screen.

Actual behaviour

The menu is closed unexpectedly.

Operating system

Arch Linux, GNOME 44.2 Wayland. This can also be reproduced in nested Weston 12.0.1.

Version of Telegram Desktop

4.8.3 and 4.8.1 (after desktop-app/patches@1d72fdb)

Installation source

Flatpak

Crash ID

N/A

Logs

(Nothing in log.txt is related to Qt & Wayland stuff and I don't think log.txt helps here, and switching versions of telegram-desktop is a little bit troublesome. Though if necessary I would make up for it.)

[taoky]

And from the console output, this message shows when the sub-popup is triggered:

qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x7fd38619bd80) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x7fd3513cbde0) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parents

This both shows in versions with (81b8) or without (9e5f) this issue.

[ilya-fedin]

I'm not sure what you expected from tdesktop to do given that you know it's a Qt issue. It's probably should reported to Qt.

[ilya-fedin]

I can't reproduce this using official binary on Plasma Wayland

[taoky]

I'm not sure what you expected from tdesktop to do given that you know it's a Qt issue. It's probably should reported to Qt.

I'm not familiar with the codebase of telegram-desktop and Qt, and then I could not give a minimal reproducible example if I would report this to Qt upstream.

[ilya-fedin]

Well, I can't either especially given that I can't reproduce. The best I can do is add this issue to #25126 but this experiment seem to fail, no one looks at the issue and helps with writing reproducers and the issues requiring reproducers are still stuck.

[taoky]

Well, I can't either especially given that I can't reproduce.

Does it help if it is reproducible inside a nested wayland compositor instance? You don't need to install a whole large desktop environment in this case.

This could let it run inside:

# flathub version
mutter --nested --wayland flatpak run org.telegram.desktop
# or official binary
mutter --nested --wayland ./path/to/Telegram

[ilya-fedin]

I remember I had a problem launching mutter nested last time, it did just crash IIRC

[ilya-fedin]

Anyway, as long as this issue is tdesktop-specific, I won't be able to write a reproducer as tdesktop UI widgets are non-trivial and I don't know them good enough to localize the bugged place. You should check the issue on other Qt 6 apps, if it happens, then you can report and say to reproduce with any Qt application/example providing the menu, if not, then we're out of luck and this is going to be a long-standing issue.

[ilya-fedin]

I reproduced with Weston, btw

[husin97]

I reproduced with Weston, btw

[ilya-fedin]

Looks like what has happened is order of some requests has changed in 6.5.1 and now the callback for the sync primitive is called earlier, after surface destruction but before focus change events. As the window no more exists and the focus hasn't changed yet, Qt thinks there's no focused window and the application is inactive so it closes all the opened popups recursively.

Qt 6.5.0:

[1729191.629]  -> [email protected]()
[1729191.647]  -> [email protected]()
[1729191.655]  -> [email protected](new id wl_callback@79)
[1729191.663]  -> [email protected]()
[1729191.737]  -> [email protected]_cursor(217, wl_surface@49, 16, 4)
[1729191.744]  -> [email protected]_buffer_scale(1)
[1729191.747]  -> [email protected](wl_buffer@94, 0, 0)
[1729191.751]  -> [email protected](0, 0, 32, 32)
[1729191.753]  -> [email protected]()
[1729191.795] discarded [unknown]@82.[event 1](0 fd, 12 byte)
[1729192.001] [email protected]_id(71)
[1729192.010] [email protected]_id(79)
[1729192.013] [email protected]_id(82)
[1729192.002] [email protected]_id(84)
[1729192.027] [email protected]()
[1729192.030] [email protected](220)
[1729192.037]  -> [email protected]()
[1729192.041]  -> [email protected]()
[1729192.065]  -> [email protected]()
[1729192.316]  -> [email protected](new id wl_callback@85)
[1729192.377]  -> [email protected](wl_buffer@90, 0, 0)
[1729192.382]  -> [email protected](0, 0, 2147483647, 2147483647)
[1729192.384]  -> [email protected]()
[1729192.387]  -> [email protected](new id wl_callback@86)
[1729192.402] [email protected](221, nil)
[1729192.406] [email protected](222, wl_surface@92, array[0])
[1729192.411] [email protected](222, 0, 0, 0, 0)
[1729192.414] [email protected](222)

the request is [email protected](new id wl_callback@79), the answer is [email protected](222).

Qt 6.5.1:

[2156390.189]  -> [email protected](new id wl_callback@62)
[2156390.223]  -> [email protected]()
[2156390.247]  -> [email protected]()
[2156390.259]  -> [email protected]()
[2156390.416]  -> [email protected]_cursor(312, wl_surface@40, 16, 4)
[2156390.433]  -> [email protected]_buffer_scale(1)
[2156390.444]  -> [email protected](wl_buffer@23, 0, 0)
[2156390.455]  -> [email protected](0, 0, 32, 32)
[2156390.464]  -> [email protected]()
[2156390.646] discarded [unknown]@59.[event 1](0 fd, 12 byte)
[2156390.664] [email protected]_id(62)
[2156390.671] [email protected]_id(56)
[2156390.675] [email protected]_id(49)
[2156390.679] [email protected]_id(59)
[2156390.865] [email protected]()
[2156390.888] [email protected](316)
[2156390.911]  -> [email protected]()
[2156391.021]  -> [email protected]()
[2156391.035]  -> [email protected]()
[2156391.321]  -> [email protected](new id wl_callback@65)
[2156391.572]  -> [email protected](wl_buffer@55, 0, 0)
[2156391.592]  -> [email protected](0, 0, 2147483647, 2147483647)
[2156391.601]  -> [email protected]()
[2156391.610]  -> [email protected](new id wl_callback@54)
[2156391.654] [email protected](316)
[2156391.673] [email protected](317, nil)
[2156391.686] [email protected](318, wl_surface@32, array[0])

The request is [email protected](new id wl_callback@62), the answer is [email protected](316).

This should probably be reported to Qt but given that this is not reproducible with other Qt applications (right? I haven't checked, I don't have any other application using 6.5.1 right now), this is specific to tdesktop's custom popups and so they should be ported to a minimum reproducible example required by the Qt reporting guidelines. Personally I'm not ready to do that work, so this is apparently stuck and deserves to be included in #25126 already included.

[NA0341]

Could this issue also be related to some other librarys?
Because I found similar issues in Qt applications using different versions of Qt.

I looked around in my installed Qt applications (not much on a Gtk+ Desktop) and quickly found something that could be related:

Native menubars work correctly when moving (in a straight line) over the tabs RTL, but LTR movement does not work. The drop-down does not switch to the next tab.
In other words: entering tab areas from below, above and right works - from left it doesn't change the drop-down.

[taoky]

Could this issue also be related to some other librarys? Because I found similar issues in Qt applications using different versions of Qt.

I looked around in my installed Qt applications (not much on a Gtk+ Desktop) and quickly found something that could be related:

Native menubars work correctly when moving (in a straight line) over the tabs RTL, but LTR movement does not work. The drop-down does not switch to the next tab. In other words: entering tab areas from below, above and right works - from left it doesn't change the drop-down.

I know that there's another bug in GNOME 44.1 that affects Qt programs in Xwayland: https://gitlab.gnome.org/GNOME/mutter/-/issues/2820. But I don't think that it is related to this issue.

[ilya-fedin]

Yeah, I heard that menus on Xwayland are broken too (was arguing with a friend that it is yet another GNOME's regression rather than a Qt one, now I have a link, thanks) and, yeah, I don't think it's related. But that makes @NA0341's test questionable (whether he has tested with Xwayland Qt applications or with native Wayland Qt applications).

[john-preston]

I've implemented a workaround, it should be fine in the latest 4.8.5 version.