Details
-
Bug
-
Resolution: Unresolved
-
P1: Critical
-
None
-
6.7.0
-
None
Description
I was testing https://github.com/labwc/labwc (I wanted a normal, simple, non-Qt, non-tiling compositor to test, and ironically what I'm trying to test is actually menus!) and found this bug: https://github.com/labwc/labwc/issues/1750 They tell me one difference between labwc and sway is when you drag the mouse over the popup window, an enter event is sent. That is true. And when we process the leave event (the mouse left the main window to enter the popup), we reset button state. So then in subsequent mouse move events and the release, the button state is NoButton, and the menu item does not react.
https://codereview.qt-project.org/c/qt/qtwayland/+/495622 looks related, but it's just a revert, and the code that it reverted didn't look so sensible either. I just wonder if we really need to reset button state there (but where else should we do it? on the enter event?)
On leave, we cannot tell whether it is entering another Qt window that belongs to the same app, because leave happens before enter. But on enter, we could tell that it's a popup window, or that we are entering a Qt window immediately after having left a Qt window, and skip this reset of button state?
It's the same on weston, and this is probably a regression anyway, thus the P1.
Attachments
Issue Links
- is required for
-
QTBUG-68080 we need to move popup event forwarding logic from QWidgetWindow::handleMouseEvent() to QGuiApplication
- Closed