diff options
author | Shawn Rutledge <shawn.rutledge@qt.io> | 2018-10-01 14:51:29 +0200 |
---|---|---|
committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2018-10-03 04:54:42 +0000 |
commit | f27a16b7bdd5f55ce210053773276c4977466efd (patch) | |
tree | 098e9de69852dbe1476a062f7711d1526a581e76 /src/qml | |
parent | 3bdb3c1d8a581906f49cd4dc89d55c04d9159f40 (diff) |
Don't get confused about the grabber during replayDelayedPress
Re-apply a fix equivalent to 8bdf33051aa679db1f060314c6ccab1cb9a77a7a
which seemingly never got included in 5.10 or newer branches.
If a ListView with pressDelay contains a MouseArea in a delegate, and
you tap the MouseArea on a touchscreen,
QQuickFlickablePrivate::replayDelayedPress() sends a saved copy of the
original QMouseEvent, and then a synthetic release, without marking it
as synthetic. (QQuickFlickable is not touch-aware in any way: it
thinks the mouse events it receives are real ones.) As a result of
sending the delayed press through, QQuickWindowPrivate::setMouseGrabber()
is called and sets the touchpoint's grabber to the MouseArea, but
does not set the core pointer's eventpoint's grabber.
Flickable then ungrabs for itself, so we have to ensure that the
ungrab affects either the actual mouse or the synth-mouse, whichever
was in use. Then because the synthetic release is not known to come
from a touchscreen, QQuickWindowPrivate::deliverMouseEvent() was
checking the core pointer's grabber and concluding that there is no
grabber. In such a case, it now checks whether touchMouseId is set,
meaning that we are somewhere between sending a synthesized press and
release, gets the touchpoint's grabber (which is MouseArea, because it
didn't reject the press), and sends the release there.
Task-number: QTBUG-61144
Fixes: QTBUG-69059
Change-Id: Ie027bef4c8de16e1cbf5d19e120cb22a3df4c037
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Diffstat (limited to 'src/qml')
0 files changed, 0 insertions, 0 deletions