Bug 56517 - Grid with all rows/columns set to Auto acts as Star
Summary: Grid with all rows/columns set to Auto acts as Star
Status: CONFIRMED
Alias: None
Product: Forms
Classification: Xamarin
Component: Samples ()
Version: 2.4.0
Hardware: PC Windows
: Normal normal
Target Milestone: 15.3
Assignee: Rustam Zaitov
URL:
Depends on:
Blocks:
 
Reported: 2017-05-16 17:58 UTC by Edward Brey
Modified: 2017-08-23 19:18 UTC (History)
7 users (show)

Tags: uwp, grid
Is this bug a regression?: ---
Last known good build:


Attachments
Sample code to reproduce (1.08 KB, text/plain)
2017-05-17 16:55 UTC, Edward Brey
Details


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 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 original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Edward Brey 2017-05-16 17:58:30 UTC
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.
Comment 1 Edward Brey 2017-05-16 18:15:55 UTC
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.
Comment 2 Paul DiPietro [MSFT] 2017-05-17 15:50:22 UTC
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?
Comment 3 Edward Brey 2017-05-17 16:55:17 UTC
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.
Comment 5 Rui Marinho 2017-06-21 13:52:47 UTC
*start
Comment 6 Rui Marinho 2017-06-21 13:53:09 UTC
Damm autocorrect .. *star
Comment 7 Edward Brey 2017-06-21 14:06:54 UTC
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."
https://developer.xamarin.com/guides/xamarin-forms/user-interface/layouts/grid/

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.
Comment 8 David Ortinau [MSFT] 2017-06-23 15:33:46 UTC
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.

Thanks
Comment 9 Edward Brey 2017-06-23 15:57:27 UTC
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.
Comment 10 Edward Brey 2017-08-19 14:23:51 UTC
Status change
Comment 11 Edward Brey 2017-08-22 12:21:07 UTC
I noticed that the general Grid documentation changed here:
https://developer.xamarin.com/guides/xamarin-forms/user-interface/layouts/grid/

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.
Comment 12 Paul DiPietro [MSFT] 2017-08-23 17:05:46 UTC
It would seem that this is a docs issue at this point, then? If so, I can reassign this to there specifically.
Comment 13 Edward Brey 2017-08-23 19:12:58 UTC
Sounds good to me. Docs issues don't cause breaking changes - just considerable confusion.