[regression/8.0.0-preview.3.8149] Regression in grid layouts in .NET 8

[filipnavara]

Description

We get many incorrect grid layout where some cells take up more space than they should. Notably, this is not the same problem as fixed recently in PR 14648, and it is not fixed as of commit e55fdb8.

Repro project running under net7.0-ios:

Repro project running under net8.0-ios:

Steps to Reproduce

1. Download the repro app linked below
2. Observe the layout is correct when compiled as net7.0-ios
3. Change the target framework in .csproj to net8.0-ios, the layout of flyout becomes incorrect

Link to public reproduction project repository

https://github.com/filipnavara/grid-layout-in-flyout-repro

Version with bug

8.0 previews

Last version that worked well

7.0 (current)

Affected platforms

iOS

Affected platform versions

iOS 16

Did you find any workaround?

No response

Relevant log output

No response

[filipnavara]

Worked fine in <MauiVersion>8.0.0-preview.2.7871</MauiVersion>, so the regression happened between .NET 8 Preview 2 and Preview 3.

[filipnavara]

cc @hartez ... This is not fixed even by the latest changes in main, as verified with the CI builds. It's likely to be caused by one of your changes. I can try to narrow it down further if necessary but the lack of CI builds from March makes that a bit tricky.

[filipnavara]

I successfully narrowed it down to changes in GridLayoutManager.cs in PR #14114. Specifically, the added check in DecompressStars (targetSize.Height > MeasuredGridHeight()) breaks it.

[hartez]

I suspect this is the same issue as #14694.

[filipnavara]

I suspect this is the same issue as #14694.

I think it's related but not the same. What happens here is that the CollectionView (or in another case in our app, Label with a long text) generates a huge size when calculated as "Auto". The row(/column) is declared as * though and in fact there is an external constraint on the size (page size, or in the other case a single cell inside a SwipeView inside a CollectionView). We expect the overall grid size not to exceed the container size which means that the * columns are supposed to shrink. The change in PR #14114, however, causes it to skip the decompression step and it does exceed the container size.

[filipnavara]

Or, to put it into the code terms:

• _explicitGridHeight == NaN
• _gridHeightConstraint == 763
• MeasuredGridHeight() == 803.66666...
• targetSize.Height == 763
• _grid.VerticalLayoutAlignment == Fill

...and with these values the condition for decompressVertical produces false, even though it produced a layout that's >803 points high, which is more than the constraint of 763.