UIWindow endDisablingInterfaceAutorotationAnimated error appears in the console when the keyboard is rejected interactively from collectionView only in iOS9

Question

I get this strange error only in iOS9:

[UIWindow endDisablingInterfaceAutorotationAnimated:] called on UITextEffectsWindow: ...without matching -beginDisablingInterfaceAutorotation. Ignoring. 

anytime I turn off the keyboard interactively by dragging it from the inside of my collector. I do not get an error rejecting the keyboard with a gesture of pressing or pressing the enter key. This is very frustrating. Even if I don't see any keyboard notifications, I still get this error when I reject this interactive keyboard. I wonder if anyone else has encountered this error and found a solution. I have an inputAccessoryView consisting of a textView installed on the keyboard.

Answer 1

I had the same issue on iOS9 but with tableView. I implemented this along with self.tableView.keyboardDismissMode = .Interactive and it worked for me.

 // Dismiss keyboard when scrolling func scrollViewWillBeginDragging(scrollView: UIScrollView) { textView.resignFirstResponder() } 

Answer 2

What to check

It seems that several other SO users have had similar experience in different environments. Check stream . Since there may be many events that cause this problem, you may need to look at the stream provided to see if a suitable use case can be found. It is not clear how you reject the keyboard, but you can call something like this a method or a sign of gesture recognition (rather than direct dismissal from a specific object):

UIApplication.sharedApplication().sendAction("resignFirstResponder", to: nil, from: nil, forEvent: nil)

From the flow provided, the nature of the problem in most cases was a duplicate call during the presentation or dismissal of the presentation. I also saw problems with connecting the segue storyboard (or in some cases it was deleted, but the xml was still in the representation of the storyboard code) and using the code (seGue) (performSegueWithIdentifier ...) for the same animation (which causes two call display / dismissal).

I would look in the log to see which calls are being logged immediately before the error, and then search the log window to see if there is an excess call. Again, there may be redundancy in the behavior / animation / layouts on the storyboard and calls made in the code.

UPDATE

The OP comments reminded me that in some cases, especially when it comes to calls during presentations / dismissals, I saw examples where the only way to successfully work with developers is to associate it with a dispatch_async call. There are some critical system calls that seem to be inoperative if the developer code is entered during the same frames.

A specific example is this call, which is within willMoveToWindow . In this case, I have a weakSelf reference to the view and just look at the newWindow value for nil (indicates that the view is rejected) before calling my code.

So, in this example, if you delete the dispatch call, the developer code will cause the entire application to crash. I assume that system transition calls (related to transposing to / from a window) may contradict those requests of developers that were at that time.

  dispatch_async(dispatch_get_main_queue(), { () -> Void in //the saved flag is true only when user hits the done button if !(weakSelf!.saved) { weakSelf?.completeNotes(nil) } }) 

Answer 3

I ran into this problem and it ruined my opinion. This is how I solve it.

I had a viewController that was presented on textFieldShouldBeginEditing . In viewController a textField , textField was set to viewDidLoad .

The solution for me is to move becomeFirstResponder to viewDidAppear .