Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.3.0, 6.3.1, 6.4.0 Beta1
-
None
-
Gnome Desktop
-
-
9e25d24b3 (dev), 391fab408 (6.5), 70e6e47fc (6.4), 60ebb044c (dev), 2a95e3f55 (6.5), e283c05af (dev), d1dd54a2a (6.5), 7f72ac18a (6.4), 04e51e9b6 (tqtc/lts-6.2), b357aca56 (tqtc/lts-6.2)
Description
I encountered a bug where two DragHandlers seemed to compete for the mouse. The `active` property of both handler flickers from false to true and back again each time the mouse moves during a drag. This happens for all three mouse buttons.
One of the handlers has `acceptedButtons: Qt.LeftButton`, and the other has `acceptedButtons: Qt.RightButton`. So it looks like a bug, I would expect that a given Handler only takes over points when its assigned button is pressed.
This was found to happen only on a single machine for a single developer of our team. I'm not sure whever said machine is running X11 or Wayland. But it is a freshly installed Fedora 36. The latest updates where checked and applied to try and solve the problem, to no avail. The rest of the team has used the code in question for months without problem.
I have tried to make a minimum reproducible example, and came up with the attached project. Interestingly, the observed behaviour is still broken, but in a different way: instead of having both Handlers activating and deactivating all the time, the second handler (for the right mouse button is always triggered. I also attach a log where I performed three drag operation with the left, right, and middle mouse button respectively. As you can see, the right button handler triggered each time.
I suspect this may have to do with some low-level button detection being buggy. The documentation of DragHandler.grabChanged is outdated for Qt 6.3, it says that we can expect an EventPoint object, while there is no documentation for an EventPoint QML type. There is however some documentation for a HandlerPoint type, backed by the C++ class QPointEvent, which seems to be the actual type now. HandlerPoint has a `pressedButtons` property in theory. So I put that in a console.log() in response to grabChanged, and this yielded Javascript's most (in)famous value : undefined.
I also tried to print all the properties of that point using this code :
function listProperty(item) { for (var p in item) console.log(p + ": " + item[p]); }
... this yielded all the properties mentioned in the documentation of HandlerPoint, plus a few extra (which seems to confirm that I am right about the type of the event), however `pressedButtons` was missing. This was another reason why I believe there may be something broken with the button identification in a Qt library.
Attachments
Issue Links
- relates to
-
QTBUG-107624 QEventPoint missing a foreign declaration
- Closed
-
QTBUG-104570 QQuickHandlerPoint has no QML_ELEMENT declaration
- Closed
-
QTBUG-102160 Improve documentation for types related to PointerHandler and QPointingDevice
- Closed