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

mouse release after Drag and Drop has item-local coordinates incorrectly mapped to window coordinates

    XMLWordPrintable

    Details

    • Commits:
      4a7771f206d4b29be549d3827c36a46679d90de6

      Description

      Text from Eike Hein:

      [There is] an internal QA ticket about the Plasma desktop icon issue in the distro I work for (Blue Systems/Netrunner). ...

      It might help if I write a bit about the debug journey that went into this:

      I naturally started in Qt Quick code. The first thing I looked at was the hover event delivery inside QQuickWindow, tracing which path causes the containsMouse==true in the wrong item. I hit on the per-frame hover event synthesis, which is based on QQuickWindowPrivate::lastMousePosition. So I took a look at all the sites that update it, found deliverMouseEvent, traced all the way up to QXcbWindow where the event comes from, and found out it's the mouse release that caps the desktop icon drag operation.

      At that point I was still confused, because the local coordinates of the release were item-local, that is: The coordinates of the release were the position of the cursor inside the dragged icon item, which made no sense, since these are window-level events. I had to find out where these coordinates come from. How do item-local coordinates get into a X mouse event?

      Then it hit me: The drag pixmap is probably an extra window, and the coordinates are item-local because the drag pixmap is a grabbed image of the dragged icon item, with the drag hotspot set to the cursor position inside the item. This is where the "item-local" coordinates came from - the release event is on the drag window.

      And sure enough, unsetting the drag pixmap and hotspot means we get a release event with totally bogus negative coordinates.

      So I fixed QSimpleDrag to mangle up sane coordinates when delayed-forwarding the release, and here we go.

      BTW, this has an additional nice side-effect: Not only does it prevent the wrong item from becoming hovered, it also means the right item does become hovered at the end of the drag. In our desktop icon drag test case, that means at te end of the drag, with the cursor above the icon that has been dragged, it becomes hovered as expected.

      The attached example demonstrates it; if the mouse is not moved after the drop, the top-left item stays hovered, like this: https://youtu.be/_5OBe9Y_SKQ

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              srutledg Shawn Rutledge
              Reporter:
              srutledg Shawn Rutledge
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes