Counter-intuitively, this is done by setting the timestamp. Every time you construct a new mouse event, you always need to call setTimestamp() for the obvious reason: the timestamp is not a ctor argument, but it's important for some event receivers. But the non-obvious reason is that QMutableEventPoint::setTimestamp() has other useful side effects: the velocity calculation is done there, sensibly enough. But to make that possible, it also looks up the persistent QEventPoint with the same ID as the one in the QMouseEvent, and that's the most important to fix QTBUG-114258 specifically. QQuickFlickablePrivate::handleMoveEvent() calculates delta as QEventPoint::position() - mapFromGlobal(globalPressPosition()) and then QQuickFlickablePrivate::drag() does the drag threshold check. If globalPressPosition() is 0,0 because the persistent QEventPoint was not passed along in the mapped QMouseEvent, that delta is nearly always over the drag threshold. So Flickable took the exclusive grab at the first possible opportunity: the second move after press. Fixes: QTBUG-114258 Pick-to: 6.2 6.5 6.6 Change-Id: Icaf7fb8fde0ef01b486ccf16852ef0f6cfb6a64c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>