Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-104761

acceptedButtons in DragHandler is apparently ignored

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • P2: Important
    • None
    • 6.3.0, 6.3.1, 6.4.0 Beta1
    • None
    • Gnome Desktop
    • Linux/Other display system
    • 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

          Activity

            People

              qt.team.quick.subscriptions Qt Quick and Widgets Team
              graslany Yves Grasland
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: