Bug 28061 - Listview iOS scrolling is calculated incorrectly after navigation or adding new items to the listview
Summary: Listview iOS scrolling is calculated incorrectly after navigation or adding n...
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.4.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Rui Marinho
Depends on:
Reported: 2015-03-16 10:14 UTC by Martin Booth
Modified: 2015-08-06 11:19 UTC (History)
7 users (show)

Tags: ios functional listview
Is this bug a regression?: ---
Last known good build:

Screencast of the bug (4.49 MB, image/gif)
2015-03-16 10:14 UTC, Martin Booth

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 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.

Related Links:

Description Martin Booth 2015-03-16 10:14:38 UTC
Created attachment 10358 [details]
Screencast of the bug

The following 2 forums posts (first one is mine) confirm this issue.



After certain actions:

1) Navigating away and returning to a listview
2) Appending items to a listview's source (e.g. observablecollection)

the listview loses the ability to scroll upwards smoothly. The taller the listview items, the more of an issue this becomes. In my case, it is impossible to scroll upwards without the screen jumping around a lot (this pretty much means scrolling upwards is unusable in my app).

It is probably (possibly?) caused by row height estimations being wrong, however there really shouldn't be a need to estimate the row heights of cells which you can scroll upwards into view since they must have previously been shown on the screen.

A possible fix may be to cache the height of rows which have previously been shown so that the EstimatedHeight method can return an actual height rather than estimation.

Please note that an incorrect height estimate when scrolling down means that the scrollbar height is not correct (not a big deal!).. however it seems that an incorrect estimate of a row height when scrolling up causes the entire list to grow or shrink each time a new cell scrolls into view (a much bigger deal that scrolling down!). As stated before though, there really should be no reason to estimate row heights when scrolling upwards though.
Comment 1 Danil Kurkin 2015-03-20 12:30:15 UTC
Little addition from me:

Platform - iOS:

Using ListView with grouping.
After refresh - list redrawn from aprox. 3rd raw.
As scrolling is available - can scroll up and see first record,
but as per user - missing first and second raw on the list - not good behavior.

Solution - I am keeping my custom renderer for now
Comment 2 Fredy Wenger 2015-04-07 03:46:00 UTC
Same problem as Martin Booth:
In my app (MatrixGuide - I have submitted it already), I show items, that are queried from a web-service in a ListView (some text and an image per item).  
If the ListView is scrolled down and an Item is taped, a detail-page to the item is showed.  
If then the back-button is taped (and the ListView is showed again, the ListView cannot be scrolled up normally, as the content then is scrambled and the scrolling stutters extremely.
This is an important bug to fix, as it prevent us to ship the app to he store.
Comment 3 Martin Booth 2015-04-07 04:15:46 UTC
If you don't mind using reflection I have put code in my forum post which at least should get this working even if it is a bit of a hack
Comment 4 Fredy Wenger 2015-04-07 05:31:34 UTC
Thanks, but this bug has to be fixed - I don't want to implement workarounds in my whole app (that bites me sometime later... :-)
Comment 5 Martin Booth 2015-04-07 07:38:07 UTC
I agree with you! A workaround like this will almost certainly stop working later.

If you're unable to ship an app without this functionality though what choice do you have?

I have been waiting for this functionality (dynamic height listview rows) since xamarin forms was released.

Hopefully this will be fixed soon. Until then we only have workarounds
Comment 6 Fredy Wenger 2015-04-07 08:03:40 UTC
Comment 7 Fredy Wenger 2015-05-18 03:23:27 UTC
It seems as this issue has gone in iOS 8.3 (but still exists in earlier iOS-versions)
Comment 8 Danil Kurkin 2015-05-18 06:46:45 UTC
There is some quick fix for earlier versions if anyone needs it

Comment 9 Rui Marinho 2015-05-18 13:07:41 UTC
Can't reproduce this issue in 1.4.2, is this still happen, can you please provide a sample project? 

Comment 10 Fredy Wenger 2015-05-18 13:20:47 UTC
@Rui Marinho:
As wrote:
- I have submitted my project (matrixguide) some time ago
- I'm not able to reproduce the issue on a iPhone 5 with iOS 8.3
=> But the bug still exists in iOS 8.1 
=> Tested a few minutes ago with iOS emulator and 1.4.3-pre2 

So you have all you need...
Comment 11 Rui Marinho 2015-05-18 17:50:43 UTC
To expatiate fixing issues we are kindly requesting customers not submit their entire app and instead attach a reduced reproduction of issues to the bug. Thank you for your understanding
Comment 12 Fredy Wenger 2015-05-19 03:40:17 UTC
Sorry - I don't have an understanding for that.
I work more then half of my time (and that are months! now) for Xamarin (testing the whole app after new releases for all platforms, create new bugzilla-entry's with no feedback - some from September 2014 have still status "New" - helping other users and so on).
I have a real life app, that have a real life problem, that has to be  solved.
I have created a detail-description how to comprehend the problem.
I don't invest further days to try make a "minimum example" (and try to build in the bug) when I have a real-time app with description that contains the bug!
Comment 13 Rui Marinho 2015-07-06 11:46:23 UTC
Hello, is this using Uneven Cells ?
Comment 14 Rui Marinho 2015-08-06 11:19:32 UTC
Should be fixed in 1.5.0-pre1