GNOME Bugzilla – Bug 736719
Menus in Qt apps displayed in wrong locations.
Last modified: 2021-07-05 14:07:07 UTC
Hi, I have recently updated to GNOME 3.13.91 from Debian experimental repository. With this version, menus (opened from the menu bar) in Qt 5 applications are placed incorrectly. Sometimes they are placed near the window center, sometimes near the top. Also, menus change not when the mouse hovers the menu bar, but when it hovers some other place. This happens with all Qt 5 apps, using any style (tested with Gtk style and Fusion style). Running "assistant" (from the standard Qt 5 installation) is enough to reprodice this issue. Two screenshots are attached.
Created attachment 286260 [details] Screenshot of Qt assistant menu in GNOME Shell 3.11.91
Created attachment 286261 [details] Screenshot of ReText menu in GNOME Shell 3.11.91
I should also add that after resizing the window (but not maximizing or unmaximizing) the issue disappears.
Are you sure that the behavior is due to a change in GNOME Shell version not a change in Qt version? (I ask because I contributed a fix for a vaguely similar problem to Qt some years ago, and it's conceivable that it might have regressed.)
Yes, I am sure. I am Qt co-maintainer in Debian and we didn't do any uploads recently.
Created attachment 286531 [details] [review] Revert "window-x11: Fix the coordinates we use in the synthetic ConfigureNotify" The coordinates in ConfigureNotify *should* be the coordinates of the frame window; using the coordinates of the client window compensated for a problem with the interpretation of StaticGravity for some clients but broke other clients. This reverts commit f4f70afe313cbae2414296028f24647dbcd65dfd.
Created attachment 286532 [details] [review] Fix computation of window positions for StaticGravity When adjust_for_gravity() was simplified (01b6445708), the correct handling of StaticGravity dropped out - fix adjust_for_gravity() to do nothing in that case.
(See https://bugzilla.gnome.org/show_bug.cgi?id=735002 for the bug reports that inspired the ConfigureNotify changes)
Pushing with release-team approval. Attachment 286531 [details] pushed as 1250afe - Revert "window-x11: Fix the coordinates we use in the synthetic ConfigureNotify" Attachment 286532 [details] pushed as 89ffcee - Fix computation of window positions for StaticGravity
Actually, this bug still exists for maximized Qt 5 windows. Test case: * Start a Qt 5 app that has menus. * If it is maximized already, unmaximize it. * Make sure that the top-left window corner if far enough from the top-left screen corner (so that the difference is visible). * Maximize the app. * Try to click on any menu in the menubar. Reproduced on GNOME 3.14.1 with Qt Assistant and ReText.
It's fixed for me here, using mutter 3.14.1.5 and Qt5 Assistant.
Strange, In Debian we have mutter 3.14.1 (not .5) but there shouldn't be any differences between them in this area. Can anybody else test this? Is there any additional debug info I can provide?
[Removing outdated "GNOME target" value.]
I'm running qt5 apps under Wayland on Arch (Gnome 3.24 betq2) and this problem is still present. Menus and context menus open in wrong position.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.