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 for Bug 56517 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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
On a Grid, if all the row or column definitions are set to Auto (or if there no such definitions, since Auto is the default), the grid acts as if all such definitions were set to Star. That is, the grid proportions its space evenly between the rows/columns, rather than setting the height/width of each row/column according to its content.
A workaround is to add an extra definition with Width/Height of 0 to the end. This causes the other definitions to have the proper semantics.
After further trial and error, I've learned more about the bug. There seem to be three underlying problems:
1. RowDefinition by default sets its height to Star, not Auto (at least when created from C#).
2. When the same RowDefinition instance is added to RowDefinitions multiple times, they don't behave as Auto. My guess is that they save a shared height state. If sharing RowDefinition instance is not allowed, this needs to be documented.
3. When a grid has fewer RowDefinition instances than it has rows, the implicitly added definitions do not behave as Auto. My guess is that the code that does the implicit logic is falling to the traps of either 1 or 2 above.
Similar problems exist with ColumnDefinitions.
A better workaround than the one in the bug description is to explicitly specify a separate RowDefinition instance with an explicit Height for each row.
Hi, could you please upload a reproduction project? Also, a few questions:
- Is the grid inside of any other layout in particular?
- Does this occur on all platforms or only certain ones?
- Have you found any existing bug reports that might match your issue?
Created attachment 22236 [details]
Sample code to reproduce
The attached code reproduces the bug. Just replace MainPage.xaml.cs in a new project with the attached file.
The bug happens when the grid is in something that make it want to use the full vertical space, such as a page or scroll view. I haven't tried when the grid is in another context.
I've only tried on UWP so far, since it's the fastest to debug on, and all three need to work anyway.
I checked for similar bug reports and didn't see any.
the default is start so this is correct
Damm autocorrect .. *star
The docs have this note:
"Note: The width values for columns are set as Auto by default in Xamarin.Forms, which means that the width is determined from the size of the children. Note that this differs from the implementation of XAML on Microsoft platforms, where the default width is *, which will fill the available space."
It's odd that the code and docs wouldn't match on such an intentional deviation from WPF. There's more going on here, too, especially regarding shared row definitions.
I've opened an issue with docs to confirm that note and correct it.
"There's more going on here"
Can you please be specific about the expected behavior and actual behavior so we can confirm it with a reproduction?
I'm unclear if the clarification that the default is Star answers some or all of the issues raised above.
By "more going on here" I was referring how it matters whether row definitions are added and whether they are aliased, even though it shouldn't. The expected behavior is that any of the following scenarios gives Auto behavior:
1. No row definitions added explicitly.
2. Row definitions added, each with unique instances, and no Width set.
3. Row definitions added, each with unique instances, and Width set to Auto.
4. Row definitions added, all sharing the same instance, and no Width set.
5. Row definitions added, all sharing the same instance, and Width set to Auto.
Items 2-5 have two variations each, one where the row definitions are set before the Children, and one where the definitions are set after the Children.
So in total, there are 9 different scenarios. The expected result is that they should all have Auto behavior, but the actual result is that some have Auto behavior and some have Star behavior.
There are a corresponding set of 9 more scenarios for column definitions. My guess is that you'll want to ensure all 18 scenarios are covered by your unit tests. I think the behavior inconsistencies will be obvious, but if you'd like any further details, don't hesitate to ask.
I noticed that the general Grid documentation changed here:
Whereas before, it said columns default to Auto, now it says they default to Star. With the "Wow! How did the docs end up 100% backward!?"-factor aside, it's helpful to have them fixed. There are still lots of problems though:
1. The docs now don't even match themselves (to say nothing of the code). It says here that columns default to Auto: https://developer.xamarin.com/api/property/Xamarin.Forms.Grid.ColumnDefinitions/
2. The general Grid documentation doesn't say what rows default to. This seems like high-priority info to provide in an overview of the grid.
3. The reference docs (https://developer.xamarin.com/api/property/Xamarin.Forms.Grid.RowDefinitions/) do specify the default for row definitions: Auto (good choice). But the code doesn't actually work. If you don't specify row definitions, the rows lay out like Star. See the attached repro on UWP.
Xamarin in general needs more attention to quality and detail, and the grid does in particular. This is a core of the UI. Please test it thoroughly and make sure it's implementation and docs are rock solid.
It would seem that this is a docs issue at this point, then? If so, I can reassign this to there specifically.
Sounds good to me. Docs issues don't cause breaking changes - just considerable confusion.