Open Radar

 
Summary:
When the first responder’s inputView has been set and an app resumes from backgrounding, the first responder is still first responder, still shows the cursor (if it’s a UITextField), but does not respond to key presses. Without a custom inputView it works as expected.

Steps to Reproduce:
1a.) Create an instance of UITextField. I’ll refer to it as "textField".
* OR *
1b.) Create an instance of a subclass of UIView that conforms to the UIKeyInput protocol, where -insertText: and -deleteBackward log their calls. I’ll refer to it as "keyInput".
2.) Set a custom input view using the viewInput property. (In the case of keyInput this involves redeclaring the viewInput property as readwrite.)
3.) Make textField or keyInput a subclass of the view controller’s view.
4.) Make textField or keyInput the first responder.
5.) Run the app.
6.) Type with a hardware keyboard to test that key input is received.
7.) Press the home button to send the app to the background.
8.) Reopen the app, bringing it to the foreground.
9.) Type with a hardware keyboard to test that key input is received.

Expected Results:
Key input should be received after resuming the app, as that is how textField or keyInput act without setting a custom input view.

Actual Results:
Key input is not received after resuming the app, even though the cursor continues to blink for textField, and textField and keyInput return YES for -isFirstResponder.

Regression:
This seems to affect every subclass of UIResponder.

Notes:
The only current workaround is to -resignFirstResponder and -becomeFirstResponder again when the app resumes.