aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/qquickvisualdatamodel/tst_qquickvisualdatamodel.cpp
diff options
context:
space:
mode:
authorShawn Rutledge <shawn.rutledge@qt.io>2017-11-27 16:30:15 +0100
committerShawn Rutledge <shawn.rutledge@qt.io>2017-11-29 09:55:16 +0000
commit8bdf33051aa679db1f060314c6ccab1cb9a77a7a (patch)
treec2bd635381813e2c57f8431ac665759b3321102b /tests/auto/quick/qquickvisualdatamodel/tst_qquickvisualdatamodel.cpp
parent787dbda672d6df4ff2336bb3afda62a233b88aaa (diff)
don't get confused about the grabber during replayDelayedPress
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 Change-Id: I494873e48af179bc63b618e881ba469b97dadf4d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Diffstat (limited to 'tests/auto/quick/qquickvisualdatamodel/tst_qquickvisualdatamodel.cpp')
0 files changed, 0 insertions, 0 deletions