iOS, input panel: be more careful before enabling QIOSKeyboardListener

The current implementation would assume that if we get a
UIKeyboardWillShowNotification, the keyboard is about to
show, and we should therefore enable the gesture.

This is problematic on an iPad with a hardware keyboard
connected, because we do actually get get a
UIKeyboardWillShowNotification on startup, even when the
standard input panel is not showing. From speculation, this
is probably because there is a little floating menu at the
bottom of the screen that lets you start dictation mode.
And in UIKit, this is probably implemented as a UIKeyboard.

This new input panel has a zero size, according to the
UIKeyboardFrameEndUserInfoKey key in the notification.
This means that we can still trust our own implementation
of QIOSInputContext::isInputPanelVisible() to be false
when a hardware keyboard is connected.

This patch will therefore only enable the gesture if we
understand the input panel to be visible, rather than
automatically assume that it is based on the
UIKeyboardWillShowNotification alone.

This will also stop the assert inside touchesBegan
from triggering.

Fixes: QTBUG-106387
Pick-to: 6.4 6.2 5.15
Change-Id: Ia3d27864325b6efb49f03fb20b711979f2d07fbf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

1 files changed, 2 insertions, 2 deletions

diff --git a/src/plugins/platforms/ios/qiosinputcontext.mm b/src/plugins/platforms/ios/qiosinputcontext.mm
index 4c4b213ba2..7a76760638 100644
--- a/src/plugins/platforms/ios/qiosinputcontext.mm
+++ b/src/plugins/platforms/ios/qiosinputcontext.mm
@@ -124,7 +124,7 @@ static QUIView *focusView()
         return;
 
     // Enable hide-keyboard gesture
-    self.enabled = YES;
+    self.enabled = m_context->isInputPanelVisible();
 
     m_context->scrollToCursor();
 }
@@ -366,7 +366,7 @@ void QIOSInputContext::updateKeyboardState(NSNotification *notification)
         // The isInputPanelVisible() property is based on whether or not the virtual keyboard
         // is visible on screen, and does not follow the logic of the iOS WillShow and WillHide
         // notifications which are not emitted for undocked keyboards, and are buggy when dealing
-        // with input-accesosory-views. The reason for using frameEnd here (the future state),
+        // with input-accessory-views. The reason for using frameEnd here (the future state),
         // instead of the current state reflected in frameBegin, is that QInputMethod::isVisible()
         // is documented to reflect the future state in the case of animated transitions.
         m_keyboardState.keyboardVisible = CGRectIntersectsRect(frameEnd, [UIScreen mainScreen].bounds);