-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GNOME 44 (Wayland): Context menu on tree items in side bar closes immediately #11576
Comments
The right click itself is received and
|
I can partly confirm the issue. The context menu does open sometimes if you're lucky. |
I have updated the description. For me it never stays open. And you can barely notice that it actually opens. Sometimes I see it flickering but it never remains open. This is a huge usability issue. Many features are completely inaccessible now. |
Removing the |
The situation with Qt 5.15 seems to get worse. |
One difference between |
Unfortunately, that doesn't make a difference 😞 But the accept() calls are nevertheless missing, also for the column headers that seem to react only when clicking twice sometimes. |
Does this also occur if the mouse is not moved between press and release? |
Not moving the mouse doesn't fix it. I am not able to access any context menus in the side bar tree. |
And even it would be backported it would not arrive before a year or so has passed. This is a shit show. |
This issue also seems to affect Zoom, so probably not Mixxx's fault. Trying to open the user's profile menu in the upper right corner shows a similar behavior recently, i.e. it closes itself immediately and is inaccessible. |
fwiw there was a simular issue on macOS a few years back with the skin settings toggle #9461 |
Fyi the same occurs in VSCode, so yeah, probably not a mixxx issue per se. |
Is there an upstream bug report we can reference? |
Can't reproduce it anymore in VSCode. I can in mixxx though. 😟 |
What is the situation here? Is the issue still happening? |
Its still happening and I can reproduce it but I'm not sure where to start debugging. |
I am afraid this is a mayor bug. Do you have a personal workaround? Since we blame Gnome 44, there must be something different in how right clicks are handeled. Maybe a glitch with touch events around Qt::WA_AcceptTouchEvents. Maybe we have another workaround that is no longer necessary? This? mixxx/src/library/sidebarmodel.cpp Line 323 in 02feca8
Is it possible, to set a breakpoint when the menu is closed and investigate the source of the closing event? Maybe in QMenu::~QMenu() and QMenu::hideEvent() |
Not really, it works every 10-20th try, so often I just right click until it works, so the issue is definitely racy. I agree that its a major bug, I just didn't find the time and motivation to look into it yet. |
So yeah, sometimes the menu closes prematurely by triggering
|
Interestingly, triggering |
Soo, I can reproduce the problem with a 60 line minimal demo. I also can't reproduce the issue when we're omitting
Just doing 1. will probably take a lot of time to get fixed. Just 2. is a little risky this late into the beta period. I propose to report upstream and switch to wayland in the meantime, reverting if we get reports of regressions. What do you think? |
Caveat for 2. is that it obviously would leave 2.3 in a broken state since it can only be applied to 2.4 |
Caveat for 1. is that the problem doesn't seem to occur under Qt6, so it probably doesn't make much sense to report to Qt. |
Are you sure this is unrelated to submenus? (tracks view context menu) How does the track menu in decks perform? |
Why not report to both with a reference to each other? Unfortunately the back trace does not directly reveal a bug. Do you have an die how the first signal is ignored on the working config? Would it be a workaround to ignore the first signal in a QMenu child class? |
I didn't look into the submenus. I just compared the context menu of the sidebar with the context menu of a track.
as expected from a UI perspective, but looking at the triggered breakpoints, the double hideEvent in which the first/premature one is ignored is super weird.
Very likely, the stacktrace of the track menu call is only 26 frames deep while the buggy sidebar one is double that. To me it almost looks like there is a nested event loop running, but I don't know enough about Qt internals to judge really whats going on here. See the
No idea, that could work but I doubt it would work for long. There is definitely something weird going on under XWayland with Doing the same inspection under Xorg works as expected (only a single hideEvent at the correct time). |
Sure, where should I report to in gnome, |
Found something very similar upstream: https://gitlab.gnome.org/GNOME/mutter/-/issues/2886 |
Can we recommend |
yes, but that only applies to 2.4. We must stick to |
Ok, than it is kind of good news to have an 2.4 soon. |
Yes, I think thats a good decision. |
Does no longer occur. Probably a Qt5 issue on Wayland that won't be fixed. |
Bug Description
Right clicking on any tree item in the side bar has no effect. Update: It actually appears for a split second, but disappears immediately without further interaction.
Opening the context menu with a right click works for tracks in the table view.
Qt 5.15.9 on a single screen.
Version
2.3.5, 2.4, main
OS
Fedora 38 / GNOME 44 on Wayland
Workaround
Start GNOME on Xorg instead of using Wayland as the display server. This bug only seems to affect the XWayland backend.
The text was updated successfully, but these errors were encountered: