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

tst_TouchMouse::hoverEnabled() is flaky

    XMLWordPrintable

Details

    • 802a5be531a9f2b1396f4ea4715c9a1dc593f778

    Description

      QQuickWindowPrivate::lastMousePosition and QGuiApplicationPrivate::lastCursorPosition can be out of sync.

      https://codereview.qt-project.org/#/c/142532/ doesn't assume that the mouse cursor moves when you touch the screen somewhere else. On eglfs platform, the mouse and touchscreen are completely independent, so you can have one MouseArea hovered by the mouse cursor, and another hovered by the touchpoint while a finger is pressed. On X11 though, the cursor probably moves when you touch the touchscreen. The X server is doing that (I think?), which means Qt will receive a mouse move event, and that will update QGuiApplicationPrivate::lastCursorPosition.

      https://codereview.qt-project.org/#/c/127724/ however uses QQuickWindowPrivate::lastMousePosition to send a hover event once per frame. If a touchpoint was used to synthesize a mouse event, then lastMousePosition will be the position of that touchpoint, which may or may not be the same as the actual cursor position.

      So the result is that tst_TouchMouse::hoverEnabled fails when flushFrameSynchronousEvents() occurs, because the test does not simulate the extra mouse move that would occur on a real X11 desktop system (nor should it, because it was designed with embedded linux in mind). Sometimes the test runs fast enough that flushFrameSynchronousEvents does not occur, and then it passes.

      In general, for the future, we need to assume that it's normal for multiple MouseAreas to be hovered by different devices at the same time. Qt 6 ought to have complete multi-device support because that's the future on Wayland etc; and we can try to get there in the mean time. QGuiApplicationPrivate::lastCursorPosition is the position of the core pointer (actual mouse cursor, assuming there's only one), but maybe QQuickWindowPrivate::lastMousePosition should be put into the QQuickPointerDevice instead? Maybe flushFrameSynchronousEvents should then send hover events for each device? But that may break assumptions elsewhere... has to be done carefully, and 5.8 is too soon now.

      Attachments

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

        Activity

          People

            frederik Frederik Gladhorn
            srutledg Shawn Rutledge
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes