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

Question

I am getting this strange error in iOS 9 only:

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

Anytime I dismiss the keyboard interactively by dragging down from within my collectionView. I don't get the error by dismissing the keyboard with a tap gesture or pressing enter. It is very frustrating. Even if I don't observe any keyboard notifications, I still get this error on this interactive keyboard dismissal. I wonder if anybody else has come across this error and found a solution. I have an inputAccessoryView consisting of a textView mounted on the keyboard.

I'm seeing this as well. Might be worth mentioning on iOS 9 only. Running same app on iOS 8 doesn't print anything in the console. — user3099609, Oct 15 '15 at 14:12
Thanks for your comment. You are right about it only occurring in iOS9. I have modified the question to reflect that. — alionthego, Oct 15 '15 at 23:45
I'm getting this on iOS 11 when swiping on the tableView of a UISearchResultsController... The app crashes after taping on a cell after that error happened — user2387149, Dec 14 '17 at 01:19

score 26 · Answer 1 · edited Jul 19 '16 at 19:52

26

I had the same problem on iOS9 but with a 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()
}

edited Jul 19 '16 at 19:52

Axe

6,285
3
31
38

answered Dec 05 '15 at 06:13

vandit

411
3
7

1

I had the same problem when there was `inputAccessoryView` on my field. They were hiding in 2 stages: keyboard and after that `inputAccessoryView`. This helped me. They are hiding simultaneously now. – Gleb Tarasov Dec 19 '15 at 13:29
this works for my with my collectionView as well. thanks very much. – alionthego May 07 '16 at 14:19
Since accepting I've noticed using this suggestion there are occasions where the inputAccessoryView actually disappears so I will have to keep searching for a solution. – alionthego May 23 '16 at 04:43
3

@izilotti it works for me but I've changed `textView.resignFirstResponder()` for `view.endEditing(true)`because I've 5 textFields. Hope it could helps someone else – Santiago Carmona González Jul 09 '16 at 20:33
1

I've noticed using this suggestion that Dismiss Interactively becomes a sort of Dismiss on Drag (which has te same error problem anyway), this will prevent user to change is mind and cancel the operation to close the keyboard (and lost the selection) when dragging. – Cue Jul 28 '16 at 12:15
BUT no .interactive effect after this code, and your code is very cool. – BollMose Oct 13 '17 at 09:26

score 6 · Answer 2 · edited May 23 '17 at 12:26

Things to Check

It appears that several other SO users have had similar experiences under a variety of conditions. Check out this thread. Since there could be a lot of things happening that cause this problem you might want to review the thread provided to see if you can find a matching use-case. It's unclear how you are dismissing the keyboard but you might want to call something like this from a method or as a gesture recognizer (rather than a direct dismissal from a specific object):

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

From the thread provided, the nature of the issue in most cases was a duplicate call during presentation or dismissal of the view. I've also seen issues where I have a storyboard segue connected (or in some cases it was removed but the xml was still in the storyboard code view) and a code-based segue (performSegueWithIdentifier...) for the same animation (which causes two display/dismiss calls).

I'd look at the log to see what calls are being logged just before the error and then do a find in the log view to see if there is a redundant call. Again there could also be a redundancy in the behaviors/animations/layouts on the storyboard and calls made in the code.

UPDATE

The comments from the OP, reminded me that in some cases especially those involving calls during presentations/dismissals, I have seen instances where the only way to successfully have a developer function work is to wrap it into a dispatch_async call. There are some critical systems calls that appear to not work well if developer code is introduced during the same frames.

A concrete example is this call which is within willMoveToWindow. In this case I have a weakSelf reference to the view and simply review the newWindow for nil value (indicates the view is being dismissed) before calling my code.

So in this example if one removes the dispatch call, then the developer code would cause the entire app to crash. I'm guessing that the system transition calls (related to transposing to/from the window) may be conflicted with whatever the developer requests 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)
     }

 })

hi. thanks for your post. i believe the duplicate call is because of the inputAccessoryView. it seems with an inputAccessoryView mounted the keyboardDidChange notification is being sent twice everytime the keyboard is shown or hidden. as if first the keyboard is dismissed and then the inputAccessoryView is brought into view. i think this is causing this and some other problems but not sure how to work around it if I like to continue using the inputAccessoryView. — alionthego, Dec 05 '15 at 06:48
I thought that the error was tied to using interactive dismissal, but in my case I tracked this error down to a manual call of `resignFirstResponder` to the a text view. Sending the `resignFirstResponder` action up the responder tree doesn't prevent the error, but at least my input accessory view is being correctly removed from the screen. I'm wondering if it has anything to do with the fact that my input accessory view keeps a (strong) reference to the the text view... will investigate and report any new information. — MathewS, Jan 18 '17 at 15:45
This should be the selected answer. In particular the update about developer actions needing to be in an async block (or nowadays a defer block) during system events makes perfect sense and solved my problem. — Alan, Sep 12 '18 at 10:10

score 2 · Answer 3 · answered Oct 20 '16 at 21:49

2

I encountered this issue and it messes up my view. This is how I solve it.

I was having a viewController being presented on textFieldShouldBeginEditing. In the viewController, a textField was set to becomeFirstResponder in viewDidLoad.

The solution for me is to move the becomeFirstResponder to viewDidAppear.

answered Oct 20 '16 at 21:49

oky_sabeni

7,672
15
65
89

I got the error message even though I did the `becomeFirstResponder` call in `viewDidAppear`. – turingtested Dec 08 '16 at 16:05

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

3 Answers3

Things to Check