path: root/src/plugins/platforms/ios/
diff options
authorTor Arne Vestbø <>2017-12-05 18:09:50 +0100
committerTor Arne Vestbø <>2017-12-06 16:17:18 +0000
commit77942a1bdf9fe22d8f076e59ce19fe9a9d7870d7 (patch)
tree53ee5c14f668c53d0381764c037a8ff10463f8ec /src/plugins/platforms/ios/
parent58a409c6dce920feb5c746a9319d0e0f1d02a233 (diff)
iOS: Try to detect and deal with delayed touch delivery due to gestures
A UIGestureRecognizer may have its delaysTouchesBegan or delaysTouchesEnded properties set, which causes iOS to not deliver touch events to the view until the recognizer has failed recognition of its gesture. In that case, the touch event is not delivered via [UIWindow sendEvent:] as usual, but via _UIGestureEnvironmentSortAndSendDelayedTouches. The latter function is apparently not reentrant, as opening a native alert dialog in response to the touch delivery will result in the dialogs's buttons to stop working, probably because they themselves use gestures. Unfortunately iOS maintains two internal gesture recognizers on iPad, of type _UISystemGestureGateGestureRecognizer, probably related to the swipe-from-bottom gesture used for multitasking. Without any workaround, these two recognizers will result in any tap on the bottom part of the screen to be delivered delayed, which may introduce stuck alert dialogs as described above. UITouch has a gestureRecognizers property, but unfortunately this property does not give us any information in the cases where we need it, so we have to use an heuristic involving a UIWindow subclass to detect the case where event delivery is delayed. As there is no way to prevent the user from recursing into an event loop when delivering the event, our only hope is to deliver the event asynchronously. Task-number: QTBUG-64577 Change-Id: I11d9caa8c4542dc80426a9e58ea555914bed433e Reviewed-by: Richard Moe Gustavsen <>
Diffstat (limited to 'src/plugins/platforms/ios/')
0 files changed, 0 insertions, 0 deletions