Btw thank you for your work on this amazing peace of software !

Hi!

I can reproduce this bug also on Arch Linux using Gnome (running embedded gnome-shell on my main compositor). 

To be precise for me it's not as consistent as you described "it works here on the first click (but not always), and never after". For me it behaves randomly, out of 20 clicks to the hamburger menu in the Bin maybe the first 4 don't work, then 3 work, then 2 don't work etc.  (same for other hamburger menu buttons)

I can also confirm that the issue does not happen using Gnome when using xwayland via QT_QPA_PLATFORM=xcb.

On my main wayland compositor Sway it works as expected without a problem.

I did the same tests using not Kdenlive but Shotcut (pretty similar dependencies as we're using) and I noticed the same problem using the menu buttons. On Krita I could not reproduce the problem (uses Qt5). All three application builds are from the Arch Linux repos but at least for Kdenlive I tried the AppImage for 25.08 and the previous 25.04.3 and got the same result.

After a bit of testing i noticed that I cannot reproduce the problem when I change the PopupMode of settingsAction to  DelayedPopup 
```
settingsAction->setPopupMode(QToolButton::InstantPopup); 
```

So the problem seems to be some kind of race condition. I found that the following workaround works while setting up the action still as InstantPopup:

```
diff --git a/src/bin/bin.cpp b/src/bin/bin.cpp
--- a/src/bin/bin.cpp	(revision d5c641096bf31887a1a08c21af396ab9a3455e09)
+++ b/src/bin/bin.cpp	(revision b9702df8fae9e8a138682685ae9fe40e972c4f1d)
@@ -1406,6 +1406,23 @@
     m_tagAction->setCheckable(true);
     m_toolbar->addAction(m_tagAction);
     m_toolbar->addAction(settingsAction);
+    // Workaround for Wayland/GNOME where InstantPopup doesn't work reliably (Menu does not appear)
+    // We use a delayed popup to avoid the race condition where the menu is not visible when the button is clicked
+    // I cannot reproduce this on Sway, the original user reported they can also not reproduce it on KDE compositor. Seems to only happend on GNOME compositor.
+    if (QToolButton *btn = qobject_cast<QToolButton *>(m_toolbar->widgetForAction(settingsAction))) {
+        if (QMenu *menu = settingsAction->menu()) {
+            btn->setMenu(nullptr);
+            btn->setPopupMode(QToolButton::DelayedPopup);
+            QObject::connect(btn, &QToolButton::clicked, this, [btn, menu]() {
+                QTimer::singleShot(0, btn, [btn, menu]() {
+                    menu->setParent(btn, Qt::Popup);
+                    const int h = btn->height();
+                    const QPoint pos = btn->mapToGlobal(QPoint(0, h));
+                    menu->popup(pos);
+                });
+            });
+        }
+    }
```

So we delay the menu opening by a single tick by queuing the request via QTimer::singleShot(0). In practice this still feels like instant. With this workaround in place i clicked the button maybe 20 times and the menu closed/opened reliably on my system.

I tried just a simple reproducer with one window, one toolbar, one button with a InstantPopup to open a menu -> This (unfortunately) worked reliable on gnome... 

So I think it's either a problem in Gnome/Mutter or Qt.

Needs a bit more research:
* try different Qt versions
* try different Gnome/Mutter/Gnome-shell versions
As we both noticed this on Arch Linux maybe just spin up a VM and test LTS and latest Ubuntu :shrug: (don't want to build my own Gnome :D).

Then maybe try again to come up with some reliable reproducer, without it, I don't think it makes sense to report this upstream...

Thank you for your investigation !

I sadly tried on a VM and both fedora and arch worked well, I guess the issue only occurs with hardware acceleration enabled, which will hurt reproducibility. 
I may try fedora / ubuntu on a spare drive but won't have time for that on the short term

This problem occurs me in Ubuntu LTS 24.04.3, Fedora 42 and 43 under gnome wayland with flatpak, appimage and packages installed from distro repository