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
Change-Id: Ia3d27864325b6efb49f03fb20b711979f2d07fbf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 9516823fce1d6f9bb7446fba8192396453af1557)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
Richard Moe Gustavsen 2022-09-23 13:48:31 +02:00 committed by Qt Cherry-pick Bot
parent 8e82e929b5
commit f34693408f

View File

@ -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);