diff options
author | Shawn Rutledge <shawn.rutledge@qt.io> | 2017-11-27 16:30:15 +0100 |
---|---|---|
committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2017-11-29 09:55:16 +0000 |
commit | 8bdf33051aa679db1f060314c6ccab1cb9a77a7a (patch) | |
tree | c2bd635381813e2c57f8431ac665759b3321102b /src/quick/items/qquickitemview_p_p.h | |
parent | 787dbda672d6df4ff2336bb3afda62a233b88aaa (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 'src/quick/items/qquickitemview_p_p.h')
0 files changed, 0 insertions, 0 deletions