Scrolling does hide input and send button partially

[paatz04]

Hello,

since iOS 8.1.1 the input field and the send button get hidden after i scroll up having the keyboard open. Do you have any idea what it might be or what I could do? Is this known bug? I'm using the latest version of pod.. (Not the development branch) Thank you very much

[jessesquires]

Hey @paatz04 - I noticed this behavior tonight, though not as you describe it.

My findings:

1. begin dragging toolbar
2. drag up and down rapidly
3. animations get glitchy, toolbar sometimes partially/completely hides behind keyboard (as pictured above)

[anilanar]

@jessesquires I'm working on replacing current implementation with inputAccessoryView. As of now, It works great for iOS7 and for iOS8 there is a minor animation curve difference between keyboard animation and scroll view animation (setting both insets and content offset). So I guess it will solve this bug. What do you say?

[jessesquires]

@anilanar - I'd love to see it!

[anilanar]

@jessesquires Currently I've accomplished docking a toolbar with a growing UITextView on top of the keyboard using inputAccessoryView and UIScrollViewKeyboardDismissModeInteractive for a typical UICollectionView without using a pan gesture recognizer, handling all discrepancies between iOS7 and iOS8, orientations and hardware keyboard.

I assume that it will be very easy to integrate it with JSQMessagesViewController, probably fixing #763, #558, #405 and many others related to keyboard frame change animations. I'm working on it so I'll let you know soon.

There will be some refactoring though, keyboard notifications will change so if there are people making use of them, it will break etc.

[anilanar]

@jessesquires I have integrated it with JSQMessagesViewController. However, there are a few restrictions:

• A height constraint must be used for input toolbar for iOS 8 because superview of inputAccessoryView (some private API class) uses AutoLayout and modifying the frame manually breaks things. Currently there is a height constraint already so I guess this is OK.
• Input toolbar is an inputAccessoryView of the collection view. For input toolbar to be visible, either the collection view or a subview of input toolbar must be the first responder. For example, using an UIActionSheet breaks this mechanism as it steals first responder status from them. This can be circumvented by using a custom UIActionSheet. I don't know what other cases can be a problem with this restriction. Edit: This is for iOS7 only. iOS8 seems to do fine.
• For iOS7: when a navigation controller is used and if another view controller is pushed and popped back, input text view will resign first responder status even if it was the first responder before pushing another view controller.

I will try to publish a proof of concept in a few days.

[anilanar]

Here we go: https://github.com/anilanar/MessagesTableViewController/commit/979e996cd7d2138f1101ded3322ca25f9c3c5495

I didn't test it for iOS7.0. It seems to work OK with 7.1 and 8.1. It probably won't look good with iPad undocking and keyboard splitting in its current state but they are fixable.

Just check the new keyboard controller and see how unpredictable iOS keyboard events are (hardware keyboard, rotations, input view accessory size changes etc.). There are some basic rules but for some cases, they are broken beyond imagination.

[anilanar]

@jessesquires Have you checked it yet? If you like the idea of inputAccessoryView way, I can work on it as I have free time nowadays.

[jessesquires]

@anilanar - not yet, but I'll try to get to it this week!

[jardamach]

@jessesquires: Hi Jesse, I noticed that you have UIScrollViewKeyboardDismissModeInteractive in JSQMessagesCollectionView. Isn't it redundant and probably also cause of this keyboard troubles? - you manage keyboard frame in your custom JSQMessagesKeyboardController already - so why using scrollview native dismiss mode. I tried removing it in your demo and it works like a charm.

[jessesquires]

@jardamach - awesome! thanks.

sounds like UIScrollViewKeyboardDismissModeInteractive was a mistake. does removing that resolve this issue?

[jardamach]

@jessesquires I believe so. I also think that in observeValueForKeyPath (JSQMessagesKeyboardController) you should convert newKeyboardFrame to contextView coordinate system:

CGRect keyboardEndFrameConverted = [self.contextView convertRect:newKeyboardFrame fromView:nil];

and then send keyboardEndFrameConverted instead of newKeyboardFrame: [self jsq_notifyKeyboardFrameNotificationForFrame:keyboardEndFrameConverted];

I noticed the comment inside observeValueForKeyPath method: // do not convert frame to contextView coordinates here // KVO is triggered during panning (see below) // panning occurs in contextView coordinates already

In my opinion NSKeyValueObservingOptionOld / NSKeyValueObservingOptionNew are not already in contextView coordinate system. I am getting values related to the entire window. Could you recheck? It solved layout problems in our customized version of your chat library.

PS: Thanks for really great work. I am big fan of this library.

[jessesquires]

Thanks @jardamach ! Super helpful info.

Much of this changed (broke) going from iOS 7 to iOS 8

[jessesquires]

main issue fixed in 97bfef2

still investing @jardamach's comment above on frames

[erysaj]

Updating -[JSQMessagesKeyboardController observeValueForKeyPath:...] breaks iOS7 The steps to reproduce are as follows (iPad iOS 7.1.2):

• enable "load extra messages" option in settings
• go to chat
• rotate to landscape
• tap on input
• slowly drag collection view down until keyboard starts moving and input text view disappears
• release your finger, keyboard should jump back to original position

Result: keyboard is presented, but input toolbar is not visible I believe I've seen this scenario in some issue's discussion, but can't find which one

On iOS8 things are even worse in this scenario: during slow dragging keyboard with toolbar can suddenly jump to half-visible position and remain at it until input loses focus.

Reverting mentioned change fixes iOS7 case, but nothing changes on iOS8. I'm investigating iOS8 case further

[erysaj]

The frame is observed on the keyboardView so the rect is in its superview coordinate space (unlike frames from keyboard notifications which are in window's), so I suppose it'd be correct to replace

CGRect keyboardEndFrameConverted = [self.contextView convertRect:newKeyboardFrame fromView:nil];

with this:

CGRect keyboardEndFrameConverted = [self.contextView convertRect:newKeyboardFrame fromView:self.keyboardView.superview];

[jardamach]

Arh, didn't notice this problem happening on iPad iOS7.1.2. Sorry about that. @erysaj's solution fixes the problem.

however, I was unable to reproduce iOS8 scenario. Everything worked fine on the current version. I just experienced some issues with media cell while scrolling. Media cell content disappeared near to bottom/top of the screen

[erysaj]

I happened to check on a device with pretty old version - 8.0 as a result +[UIDevice jsq_isCurrentDeviceBeforeiOS8] worked incorrectly - it compares current version to @"8.0.0" so the window height was determined as if it is iOS7 and caused a mess.

[jessesquires]

thanks @erysaj and @jardamach ! :+1:

re-opened this issue and tagged it for the 7.0.1 milestone