Open Radar

 
Summary:
When a view is transplanted e.g. from a window's contentView to a new view, by using addSubview: to add it to the new view, the constraints on the view's former superview are left lingering. This leads a variety of a unexpected and hard to debug consequences.

Note that the bug does not exhibit itself if the view is explicitly removed from the old superview. The bug in this case then is specifically that using -addSubview to move a view from one hierarchy to another does not cause the expected removal of constraints that you would see when calling -removeFromSuperview first.

Steps to Reproduce:
I'm attaching a sample project that demonstrates the bug. To see the bug quickly, open and run the project. Notice the views in the window are clipped and drawn in unappealing locations. Now change the #define WORKAROUND_BUG to 1 and run again. You'll see comments in the code explaining that the workaround is to explicilty remove the view from superview before transplanting it.

The gist of the steps for reproducing the bug in words is as follows:

1. Create a nib-based project with autolayout enabled.
2. Define constraints in the xib for a view "view1" within a window's  content view.
3. At run time, transplant view1 into a new, custom view that is not associated (yet) with a window:

[newView addSubview:view1]


Expected Results:
The constraints on [window contentView] that pertained to view1 should be removed.


Actual Results:
The constraints pertaining to view1 are left on the window's contentView, and will cause issues particularly if view1, in its new configuration inside some other view hierarchy, is added back into the window.


Version:
10.9 13A603

Notes:


Configuration:


Attachments:
'DanglingConstraints.zip' was successfully uploaded.