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:
parent
8e82e929b5
commit
f34693408f
@ -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);
|
||||
|
Loading…
x
Reference in New Issue
Block a user