[Windows] CollectionView GroupHeader doesn't fill space horizontaly

[Vroomer]

Description

GroupHeader doesn't fill available horizontal space even if you set HorizontalOptions="Fill". This is not a new bug, I noticed the behaviour in .NET 7 as well. Android is correct. iOS wasn't tested.

Steps to Reproduce

1. Load the repository and run the app.
2. Observe the spacing around yellow border.

Link to public reproduction project repository

https://github.com/Vroomer/MAUI-CollectionView-templates-bugs.git

Version with bug

8.0.0-rc.2.9511

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

8.0.0-rc.2.9511

Affected platforms

Windows

Affected platform versions

Windows SDK 10.0.19041.0

Did you find any workaround?

No response

Relevant log output

No response

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[XamlTest]

Verified this on Visual Studio Enterprise 17.9.0 Preview 1(8.0.3). Repro on Windows 11, not repro on Android 14.0-API34 with below Project: MauiApp10.zip

[BFuchshofer]

I also can reproduce this issue on .net 7 iOS. The group footer of the CollectionView is also affected. I can't get the header/footer positioned correctly. HorizontalOptions does nothing.

[Bloodyairtimer]

I have been able to 'fix' the issue by binding the WidthRequest of the template container to the Width of the Collectionview.

WidthRequest="{Binding Width, Source={x:reference collectionViewName}}"

As I don't want this binding on the other platforms I have a Headless contentview around it with only the above binding on the WinUI platform

[EmanterolaDN]

Even is duplicate of #18699 Here is set a workaround by @Bloodyairtimer . I've recently applied it and it's working... Thx btw!

[DanTravison]

I'm seeing this same behavior on Windows 11 with Maui build 9.0.50.

[Dhivya-SF4094]

This issue is not reproducible on the Windows platform using .NET 9 with the 9.0.71 NuGet version.

[DanTravison]

I'm still seeing this on 9.0.80.

I have a repro in my Glyph Viewer project.

There are comments in FontFamilies.xaml where the issue occurs.

[Dhivya-SF4094]

@DanTravison, Thank you for sharing the sample project. I was able to reproduce the issue using the Glyph Viewer project with the latest NuGet version (9.0.80).

Upon further analysis, I found that the issue does not occur in the simplified sample attached to the original report.

In the Glyph Viewer project, the problem is related to the layout configuration: the FontFamiliesView page sets to the Grid.ColumnDefinition as Auto for the column containing the CollectionView. When I changed the column definition from Auto to *, the layout behaved as expected and the issue was no longer reproduced.

To avoid spacing issue, please use * instead of Auto for the grid column in your MainPage.

[DanTravison]

@Dhivya-SF4094, While that does solve the header issue, it completely distorts the main page. Instead of the FontFamiliesView auto-sizing, it is splitting the available space with the FontGlyphsView and using much more width that is required.

Perhaps I misunderstood your suggestion.

That also appears to beg the question...

Why does Auto in the parent grid prevent the CollectionView's header items from filling the width.

Two other workarounds I've tried are less than ideal:

• Use a fixed width + a tooltip but that's not viable on mobile.
• Use relative '' values, such as 1, 4*, Auto

In both cases, I'm reluctant to use hard-coded values.

Thanks.

[DanTravison]

Drilling into this further, I found I could workaround this without changing the column to '*' doing the following:

1: Capture the longest string when I build the font list 2: Measure the width of this string with padding using StringSizeService.GetStringSize. 3: Bind the value to CollectionView.WidthRequest.

The screen shot shows the result.

This implies to me that there is a disconnect in CollectionView's measurement of items and header items when the width isn't explicitly set. I think it's reasonable to expect it to size the header items appropriately when no explicit width is set.

Thanks.

[DanTravison]

I don't understand why this is closed as completed. My workaround is for a very narrow case where the group header template is a single label and the contents are known in advance so I can guestimate a width without having to measure every item.

My other use cases are not as straight forward requiring me to either know intimately the layout of each template or to instantiate and measure them in advance. Regardless of which I use, I end up replicating the work CollectionView already performs.

Thanks.