Open Radar

 
Summary:
A UITextView that has multiple pages worth of text content has an issue preserving the content offset beginning or ending editing. Showing or hiding the keyboard appears to trigger a superfluous -layoutSubviews which unnecessarily change the contentSize and contentOffset.

Steps to Reproduce:
0. Launch the provided sample app
1. Scroll down to the first arrow
2. Align arrow with bottom of navigation bar
3. Tap at the indicated position to start editing
4. Re-align the arrow with bottom of navigation bar
5. Tap on the resign button
6. Scroll to very bottom of the text view
7. Scroll as far up as possible to see the bottommost arrow over the keyboard.
8. Tap to the right of the arrow and type a few characters. Again there is some weird flickering scroll movement, but at least we see the cursor.
9. Push the resign button again.

Expected Results:
- step 3 should not change scroll position
- step 5 should not change scroll position
- step 9 should change the scroll position such that the bottommost text is still visible (i.e. adjusting the inset should animate together with the frame of the keyboard)

Actual Results:
- The scroll position shifts at all 3 indicated steps
- The user is getting confused and frustrated

Version:
iOS 6.3 (12F70)

Notes:
I also found that the contentSize appears to change while scrolling downwards making it unreliable for use in calculations. As a workaround you can use -sizeThatFits which determines  the actual contentSize. One problem here is though, that this also triggers a layoutSubviews.

Bonus Bug: If the keyboard is showing in the sample all, when run in simulator, the scrolling is very jerky and the scroll indicator jumps around (probably every time the contentSize is being adjusted)

Configuration:
iPhone 6

The mentioned sample app is the TextViewScrollBug on https://github.com/cocoanetics/RadarSamples