If QGuiApplicationPrivate::processTouchEvent() at some point saw that a touch event was not handled, and called processMouseEvent() to send a synth-mouse event, that always uses an eventpoint with id 0 (a mouse does not have multiple eventpoints: so by convention, the eventpoint in a mouse event always has id 0). Next time the touchpoint is updated, the persistent synth-mouse eventpoint has not been updated yet, but it may turn out to be "closer". We don't want its possibly-null target to override the target that we would otherwise choose: i.e. in this case keep going to see if there is an actual touchpoint with a target. In the imagegestures example, the image widget fills the whole window. If we attempt a 3-finger swipe gesture, within the bounds of the window, the image widget should always get all the touchpoints; but often it was not getting them, because findClosestTouchPointTarget() often got distracted by the persistent eventpoint that has id=0 and target=null. If its stored position happened to be closer than any of the others, the target would remain null. This made the swipe attempts fail often: QSwipeGestureRecognizer::recognize() expects that after it has begun to see 3 touchpoints, they will continue to be there in subsequent events (a reasonable expectation, just as Qt Quick multi-touch components are expecting). And since 1783b048fd4c97e86de4a1122f64eb2afa603cbf the expectation has been that a touchpoint that doesn't move will also be included, with state=Stationary. So it doesn't make sense to just omit some of the points some of the time, when it's perfectly obvious that all points are inside the widget that is filling the whole window. Pick-to: 6.11 6.10 6.9 6.8 Task-number: QTBUG-46195 Task-number: QTBUG-138601 Change-Id: Ie559e62a143f4ca506f15dcb678f39e501e24072 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>