Bug 31216 - Control enabled states wrong in scrolling ListView
Summary: Control enabled states wrong in scrolling ListView
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 1.4.2
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Seth Rosetter
Depends on:
Reported: 2015-06-18 06:51 UTC by Trevor Prinn
Modified: 2016-04-10 01:58 UTC (History)
9 users (show)

Tags: ac slider listview cells
Is this bug a regression?: ---
Last known good build:

Test app to demonstrate the problem on Android (18.02 KB, application/x-zip)
2015-06-18 06:52 UTC, Trevor Prinn
ListView binding bug on Android (46.89 KB, image/jpeg)
2015-06-25 21:44 UTC, Simon Taylor

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 Trevor Prinn 2015-06-18 06:51:16 UTC
The attached app displays a ListView in which each row contains a disabled slider and a switch, which sets the enabled state of the slider when toggled. When displayed on a screen in landscape so that scrolling is required, setting a slider enabled near the top and then scrolling down causes some of the sliders at the bottom of the list to be enabled. On scrolling back up the wrong sliders are sometimes enabled at the top of the list.

The cells themselves do not seem to be re-used, but it has been suggested that perhaps the renderer is, and the problem is in there.
Comment 1 Trevor Prinn 2015-06-18 06:52:11 UTC
Created attachment 11662 [details]
Test app to demonstrate the problem on Android
Comment 2 Simon Taylor 2015-06-25 21:43:37 UTC
There seem to be general problems with bindings in ListView with scrolling. In the screenshot I've attached every element should have a date in the first row. The elements with dates change when scrolling up and down.

The binding is
                  m => m.EffectiveDate, BindingMode.Default,
                  new ShortDateConverter());

MessageModel.EffectiveDate is not nullable. ShortDateConverter just returns dateTime.ToString(culture.DateTimeFormat.ShortDatePattern);

I'll log a separate bug with a repro.
Comment 3 Simon Taylor 2015-06-25 21:44:03 UTC
Created attachment 11743 [details]
ListView binding bug on Android
Comment 4 irwincollin 2015-07-09 09:04:35 UTC
This problem happens for me in many more ways than just IsEnabled and with more than just Sliders and Switches. This bug affects my pickers, my custom pickers, my buttons, and my custom buttons. It affects both the graphics and the high-level state, but does not affect my model (low level state). 

That is, once I select one button, many other buttons begin to break in terms of graphics:
Font size, color, button scale all change sporadically. 

In addition, the state is odd, too, in that the model remains uncorrupted for picker #4, but rather it seems picker #4 is displaying and affecting picker #2 instead, perhaps.

The sporadic changes in graphics seem to be partially duplication and rearrangement, but also delayed and incorrect rendering.

I hope the priority of this bug report can be raised, as it severely hinders my application and requires extensive workaround (constantly refreshing listrows, or constantly adding-removing elements from pickers to force a refresh).
Comment 5 irwincollin 2015-07-09 10:38:24 UTC
As a workaround I created an interface: 
        public interface IRefreshable
            void ForceRefresh();

and a custom cell:

    public class TaskCell : ViewCell
        private readonly List<IRefreshable> refreshables = new List<IRefreshable> ();
        private bool needsRefresh = true;

        protected override void OnChildAdded (Element child)
            base.OnChildAdded (child);
            needsRefresh = true;

        protected override void OnChildRemoved (Element child)
            base.OnChildRemoved (child);
            needsRefresh = true;

        protected override void OnAppearing ()
            base.OnAppearing ();

            if (needsRefresh) {
                needsRefresh = false;
                foreach (View v in ViewHelpers.GetAllViews ((Layout)View)) {
                    var tp = v as IRefreshable;
                    if (tp != null) {
                        refreshables.Add (tp);

            RefreshRefreshables ();
        private void RefreshRefreshables() {
            foreach (var v in refreshables) { 
                v.ForceRefresh ();

ForceRefresh looks something like this:
	void IRefreshable.ForceRefresh ()
            foreach (View v in GetRelevantViews ()) {
                v.BackgroundColor = v.BackgroundColor.AddLuminosity (0.000001);

And everything works fine now. The setting of background color seems to force the renderers to redraw in the correct places.
Comment 6 Jason Smith [MSFT] 2016-04-10 01:58:18 UTC
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Forms. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction.
For your convenience, we have created some reproduction best practices viewable here: https://gist.github.com/jassmith/92405c300e54a01dcc6d

Warm regards,
Xamarin Forms Team