Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 15366 [details]
Test case of bug
If you have an UICollectionView and you're using resizable cells using EstimatedSize, then calling ReloadData or ReloadSections on the UICollectionView will break cell placement.
But only if you scroll down to the bottom of the UICollectionView and the top is no longer visible.
It will, however, work just fine if you use ItemSize instead, but that means all cells have the same size.
In the attached test case I have two sections and a header for each section.
The two headers are called "Header 1" and "Header 2".
Each section contains five cells per row, difference being the cell height.
Every cell will call ReloadData on the UICollectionView when clicked.
Every cell is uniquely named (Cell 0, Cell 1, Cell 2, ... Cell n)
If you stay at the top and you can see both headers, pressing a cell will reload the cells just fine.
Nothing is wrong here.
If, however, you scroll down to the bottom row, and then press a cell, ReloadData will mess up the first row in the second section.
More specifically all the cells in the first row will have moved up into the header, and be stuck on top of each other.
If you scroll down so they're no longer visible and up again, you'll see the label in the cell change name.
Removing the headers doesn't solve the issue, I already tried that.
Attached is a test case which will demonstrate the issue.
I can reproduce this with the provided sample, but it looks very much like a bug in iOS itself, and not a bug in Xamarin.iOS (since we're just a thin binding on top of the iOS binding).
I recommend contacting support (see the yellow bar at the top) or using our forums / stackoverflow / Apple's forums to ask other users about this problem and see if there's a workaround available.
If you're still convinced this is a bug in Xamarin.iOS, please provide an equivalent Xcode project that works fine (and reopen the bug) and we'll have a look.