submenu shows up far from parent on Wayland

[lilydjwg]

Steps to reproduce

1. maximize telegram
2. right click on the message input
3. choose to change text format

Expected behaviour

The submenu is shown near the parent entry.

Actual behaviour

See screenshot:

PS: I tried with the static binary from official site, the menu even doesn't pop up. If it were not maximized, and moved near the bottom of screen instead, this issue would also occur.

Operating system

Arch Linux, wayfire

Version of Telegram Desktop

3.6.1

Installation source

Other (unofficial) source

Logs

No response

[Aokromes]

plz try downloading official version from https://desktop.telegram.org

[lilydjwg]

Did you read my report? I tried; it was worse.

To be precise,with the official build, you need to move the window very close to screen bottom, and resize the window relatively large to make this issue significant.

[ilya-fedin]

Would be nice to get some help with this. I don't understand how to make menus work as expected on Wayland since there's no way to get window position.

[lilydjwg]

I don't understand how to make menus work as expected on Wayland since there's no way to get window position.

I don't know about Qt, but in Wayland protocol, you specify the position of a popup relative to its parent, and in case of reaching edges, what should be done (sliding or flipping etc), via the xdg_positioner interface. GTK 3 has similar APIs to position a popup.

[ilya-fedin]

Qt doesn't have such APIs, it has pre-defined xdg-positioner flags for all windows of type Qt::Popup (what menus are). We need xdg_positioner::set_offset I guess in order to set shadow extents, but we have no access to that API.

[lilydjwg]

Sad :cry:

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[lilydjwg]

No, I'm still interested this issue to be resolved. Inactivity only means that nothing could be done currently but the problem doesn't disappear on its own.

There should be some way to keep inactive issues open if stalebot is enabled.

[ilya-fedin]

but the problem doesn't disappear on its own.

Are you sure? My experience tells they do. Can you re-check?

[lilydjwg]

I just tried version 4.1.1 official build, it still misaligns, not as high as the above screenshot though.

[ilya-fedin]

Can you check 4.2.0? It uses newer Qt

[lilydjwg]

It got updated again? I'll update and see soon.

[lilydjwg]

Same with 4.2.0:

I have another build with Arch's Qt6 and it has exactly the same issue too.

[ilya-fedin]

This seems to be the best thing Qt can do with its design...

[lilydjwg]

I just notice that there is a warning message from Qt:

qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x7f70967fcf60) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x7f704a3f23a0) 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

I don't know what it means but it may help?

[ilya-fedin]

This is about some Wayland's weird thing with strict hierarchy that tdesktop can't obviously follow due to being a cross-platform application, it seems Qt does a good job here by guessing and automatically changing the parents

[Aokromes]

No, I'm still interested this issue to be resolved. Inactivity only means that nothing could be done currently but the problem doesn't disappear on its own.

There should be some way to keep inactive issues open if stalebot is enabled.

slatebot helps us to find fixes issues witch their issues aren't linked on fix and closed on fix time.

[ilya-fedin]

Or which are fixed on their own due to reporter's environment changes or third-party libraries changes

[ilya-fedin]

This issue is now a part of #25126

[lilydjwg]

Things get worse with 4.2 with context menus on messages affected: they may appear high above the click position when the message is too below, but when I hover below the menu, items on the menu actually get highlighted, i.e. when I click empty space below the menu, trying to dismiss the menu, an item is activated instead.

The highlighted item issue has been around but this time, the menu shifts above, leaving a lot of space to accidentally trigger it.

Tested on both official build and a build with Qt6.

[ilya-fedin]

It's due to reactions I guess, the top-left point of the menu window is where the reaction bubble (way upper than the cursor), so it becomes new bottom(-right) point. I have no idea how to fix that.

[jeanas]

In case it helps anyone, we saw weird things like this in the Frescobaldi (https://github.com/frescobaldi/frescobaldi/issues/1462) and it was caused by submenus not being owned by their parent menu.

(NB I'm a random lurker, I just stumbled upon this issue while searching the net for the warning message.)

[jeanas]

(https://bugreports.qt.io/browse/QTBUG-68636?focusedCommentId=491743 also looks related.)

[ilya-fedin]

I don't believe the problem is in the parents in tdesktop case, but you're free to prove that

[ilya-fedin]

QTBUG-87303 just got a follow-up commit that changes constraint strategy on Wayland, so this can become unreproducible in Qt 6.5.0-beta4

[lilydjwg]

It's fixed in Qt 6.5, thanks!