diff options
author | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2017-12-05 18:09:50 +0100 |
---|---|---|
committer | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2017-12-06 16:17:18 +0000 |
commit | 77942a1bdf9fe22d8f076e59ce19fe9a9d7870d7 (patch) | |
tree | 53ee5c14f668c53d0381764c037a8ff10463f8ec /src/testlib/qxctestlogger.mm | |
parent | 58a409c6dce920feb5c746a9319d0e0f1d02a233 (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 <richard.gustavsen@qt.io>
Diffstat (limited to 'src/testlib/qxctestlogger.mm')
0 files changed, 0 insertions, 0 deletions