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 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.
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
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.
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
Thanks, but this bug has to be fixed - I don't want to implement workarounds in my whole app (that bites me sometime later... :-)
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
It seems as this issue has gone in iOS 8.3 (but still exists in earlier iOS-versions)
There is some quick fix for earlier versions if anyone needs it
Can't reproduce this issue in 1.4.2, is this still happen, can you please provide a sample project?
- 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...
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
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!
Hello, is this using Uneven Cells ?
Should be fixed in 1.5.0-pre1