Bug 40432 - iOS ListView is scrolling to the wrong ViewCell after a call to ForceUpdateSize.
Summary: iOS ListView is scrolling to the wrong ViewCell after a call to ForceUpdateSize.
Alias: None
Product: Forms
Classification: Xamarin
Component: iOS ()
Version: 2.1.0
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-04-15 09:59 UTC by Nigel Palmer
Modified: 2017-01-02 14:22 UTC (History)
6 users (show)

Tags: iOS ac
Is this bug a regression?: ---
Last known good build:

iOS ListView with dynamically sizing ViewCells (4.68 MB, application/x-zip-compressed)
2016-04-15 09:59 UTC, Nigel Palmer

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Nigel Palmer 2016-04-15 09:59:21 UTC
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.
Comment 1 Nigel Palmer 2016-09-16 15:12:54 UTC
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?
Comment 2 Matthew 2016-09-16 15:36:10 UTC
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.