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 for Bug 40432 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Created attachment 15734 [details]
iOS ListView with dynamically sizing ViewCells
Steps to reproduce (Tested on simulator iPad Retina iOS 9.3):
1. Compile and run the attached application. (ResizeIssues)
2. Scroll down to section 10 and tap the plus sign.
3. Tap the "more" button that appears.
4. Scroll down to section 13 and tap the plus sign. [THE LIST THEN SCROLLS BACK UP TO SECTION 10 REMOVING SECTION 13 FROM VIEW]
5. Scroll to Section 4 and tap the plus sign.
6. Tap the "more" label that appears.
7. Scroll back to section 13 and tap the "More" label. [THE SCREEN SCROLLS UP SO THAT WE CAN SEE THE TOP OF THE BOTTOM OF SECTION 4 AND THE TOP OF SETCION 10]
8. Scroll back to section 13 and tap the "Less" label. [SCREEN SCROLLS UP SO WE CAN SEE ALL OF SECTION 10]
9. Repeat the process many times of scrolling to section 13 and tapping the "More"/"Less" label. [DO THIS ENOUGH TIMES AND THE LIST WILL SCROLL UP TO SHOW ALL OF SECTION 4.]
Repeating step 9 many times seems to cause the list to scroll to one of 3 positions:
a. Section 10 visible.
b. Bottom of section 4 visible, top of section 10 visible.
c. Section 4 visible.
This can be reproduced with other combinations of selections.
I also tested on an iPad and the sequence of steps detailed above did not manifest the problem but it did still occur whilst tapping around on the "plus/minus" and "more/less" controls. The problem occurred less on an iPad but still occurred intermittently.
I have yet to find a work around to this problem. All attempts to programmatically scroll to the selected item seem to get overridden by the behaviour detailed above.
Could it please be fixed.
We have had another look at this and the problem still exists in the latest version of Xamarin Forms.
The problem can even be seen in your own test project:
Do you have any plans to fix this problem?
Much research has implied this is caused by an issue introduced in iOS when using the tableView.RowHeight = UITableView.AutomaticDimension option.
It is necessary to ensure that HeightForRowAtIndexPath provides the current height of all rows in the TableView, otherwise when tableView.ReloadRows is called it attempts to reset the ContentOffset of the list incorrectly based on an incorrect understanding of how high each row in the TableView is.