Summary:
When using "embedded" UICollectionViews and UICollectionViewFlowLayout (e.g. a vertical, full-width collection view that has cells with horizontal UICollectionViews in them), if you change the contentInset property of one of the embedded collection views before changing the dataSource (changed because the cells are reused), UICollectionView will throw when validating layout attributes.
This seems to be because changing the contentInset triggers an invalidation pass, setting some internal state that disallows another invalidation after changing the dataSource (which should trigger an internal reloadData and invalidation).
This issue can be avoided by using a custom UICollectionViewFlowLayout subclass and overriding:
But that is both undocumented and unexpected behavior.
This also only occurs when changing the contentInset.top between reused collection views.
Steps to Reproduce:
Open uploaded example app.
Scroll to bottom.
Crash (100% of the time)
Expected Results:
UICollectionView shouldn't throw an exception, the views should be laid out with the correct contentInset, and the dataSource change should result in a reloadData call that invalidates on layoutSubviews.
Actual Results:
UICollectionView crashes, throwing an exception like:
'NSInternalInconsistencyException', reason: 'UICollectionView received layout attributes for a cell with an index path that does not exist:
Summary: When using "embedded"
UICollectionViews
andUICollectionViewFlowLayout
(e.g. a vertical, full-width collection view that has cells with horizontalUICollectionView
s in them), if you change thecontentInset
property of one of the embedded collection views before changing thedataSource
(changed because the cells are reused),UICollectionView
will throw when validating layout attributes.This seems to be because changing the
contentInset
triggers an invalidation pass, setting some internal state that disallows another invalidation after changing the dataSource (which should trigger an internalreloadData
and invalidation).This issue can be avoided by using a custom
UICollectionViewFlowLayout
subclass and overriding:But that is both undocumented and unexpected behavior.
This also only occurs when changing the contentInset.top between reused collection views.
Steps to Reproduce:
Expected Results:
UICollectionView
shouldn't throw an exception, the views should be laid out with the correctcontentInset
, and the dataSource change should result in areloadData
call that invalidates on layoutSubviews.Actual Results:
UICollectionView
crashes, throwing an exception like:Version: iOS 10.3.2
Notes:
Configuration: iPhone 7+, iPhone 7 Simulator
Attachments: UICollectionViewContentInsetCrash.zip