Open Radar

 
Summary:
Whereas changing the zoom scale of a UIScrollView alters its contentSize accordingly, its contentInsets are left unchanged. This leads to strange behaviour, particularly in combination with zoomBouncing (see enclosed sample).

Steps to Reproduce:
The attached project TestZoomBouncing.zip creates a scrollview containing a blue box and a red box (the red box is initially offscreen to the right).

1) Run the project as-is.
2) Pinch to zoom out while the blue box is filling the screen.
3) Pinch to zoom out while the red box is filling the screen.
4) Un-comment the line marked "// blue" and re-run.
5) Pinch to zoom out.
6) Re-comment the line marked "// blue", un-comment the line marked "// red", and re-run.
7) Pinch to zoom out.
8) Change the value of "m" to something larger and re-run.
9) Pinch to zoom out.

Expected Results:
When the contentInsets constrain the scrollview to only the red box, zoom-bouncing should behave similarly to when the scrollview is constrained to only the blue box.

Actual Results:
Zoom-bouncing behaves erratically in the case of the red box. Increasing the value of "m" (i.e. the separation of the boxes) increases the severity of the erratic behaviour.

Regression:
No.

Notes:
Some discussion of this bug has already taken place in DTS TSI #158540533.
I believe that the proper fix for the behaviour described in the sample project involves zooming the contentInsets along with the contentSize. In the comment case (all content zoomed) this makes better sense than not zooming it; in the case of mixed zoomed and unzoomed content, full layout already has to occur anyway (because the contentSize is zoomed).