Bug 44738 - MinimumHeightRequest ignored in ListView Header and Footer templates
Summary: MinimumHeightRequest ignored in ListView Header and Footer templates
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.1
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-09-26 13:41 UTC by John Hardman
Modified: 2016-12-20 15:00 UTC (History)
4 users (show)

Tags: MinimumHeightRequest ListView DataTemplate Header Footer
Is this bug a regression?: ---
Last known good build:

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 John Hardman 2016-09-26 13:41:37 UTC
With a template used for a ListView's header and footer, if the template defines a MinimumHeightRequest on the content (in the example below, this is a Label), the MinimumHeightRequest is ignored. In the code below, MinimumHeightRequest is set to 144, but this is ignored and the actual Height is much less than 144.

Even if the Label is wrapped in a ContentView, StackLayout or Grid, with the wrapper having MinimumHeightRequest set to 144 and AndExpands on the VerticalOptions, the ListView's header or footer still does not use the minimum height specified.

using System.Windows.Input;

using Xamarin.Forms;

namespace ViewsUsingXamarinForms
    public class MyAppMenuHeaderFooterTemplate : DataTemplate
        public MyAppMenuHeaderFooterTemplate(
            string textProperty,
            string textColorProperty,
            string textBackgroundColorProperty,
            ICommand command,
            object commandParameter) : base(() =>
                Label label = new Label
                    HorizontalOptions = LayoutOptions.Center,
                    VerticalOptions = LayoutOptions.StartAndExpand,
                    VerticalTextAlignment = TextAlignment.Center,
                    MinimumHeightRequest = 144,
                    LineBreakMode = LineBreakMode.WordWrap,
                    FontSize = Device.GetNamedSize(NamedSize.Small, typeof(Label))

                label.SetBinding(Label.TextProperty, textProperty);
                    new Binding(
                    new Binding(

                return label;
            // no-op            

    } // public class MyAppMenuHeaderFooterTemplate : DataTemplate

} // namespace ViewsUsingXamarinForms

// eof
Comment 1 adrianknight89 2016-09-26 19:25:36 UTC
Minimum height/width request seems to be ignored by all elements. I was working on it last night. Found a fix but it broke many unit tests. They need to fix this at the level of VisualElement & Layout.
Comment 2 John Hardman 2016-09-27 10:40:11 UTC
Should have mentioned, I am using XF
Comment 3 adrianknight89 2016-09-27 11:23:39 UTC
See https://github.com/xamarin/Xamarin.Forms/pull/386
Comment 4 Jason Smith [MSFT] 2016-12-19 19:54:44 UTC
While we wish Minimum Width/Height worked differently, such a change now would be a large breaking change to many users and as such will not be fixed.
Comment 5 John Hardman 2016-12-19 23:59:00 UTC
If MinimumHeightRequest and MinimumWidthRequest are going to be intentionally ignored, can they both be marked as Obsolete please, with an appropriate message to explain that they simply don't do what any developer would expect?
Comment 6 david 2016-12-20 04:05:12 UTC
I would honestly prefer a breaking change that results in properly-working software over leaving bugs in the system forever. It's a great relief for maintenance programmers to finally be able to delete all the yucky work-around code that compensates for bugs like this.
One way or another something has to change - either obsoleting the broken properties, creating new ones that work, or fixing the bugs.
The least disruptive path is to create new working properties, but the broken ones have already captured the best names for them. So my vote (probably doesn't count for much, but here goes anyway) is for fixing the bugs.
Comment 7 John Hardman 2016-12-20 08:40:35 UTC
David/Jason - I agree completely. For this particular bug, I would not have an issue with it being a breaking change. The properties are well named, so if people have written code that would break by them suddenly working the way their names suggest, then those developers should (a) be in a minority, and (b) be prepared to fix their own code that uses these properties.

However, if Xamarin are not going to fix this, the next best thing (ok, the least worst thing as it's still not good) is to mark these properties obsolete.