Fix CollectionView group header not stretching to full width on Windows#34710
Fix CollectionView group header not stretching to full width on Windows#34710rmarinho wants to merge 8 commits into
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34710Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34710" |
There was a problem hiding this comment.
Pull request overview
Fixes a Windows-specific CollectionView grouped header layout issue by updating the default WinUI header container styles to allow header content to stretch full width, and adds a new UI regression test (HostApp page + Appium/NUnit test) for issue #23038.
Changes:
- Updated WinUI
ListViewHeaderItem/GridViewHeaderItemstyles to useHorizontalContentAlignment="Stretch"and remove default padding. - Added a HostApp reproduction page for a grouped
CollectionViewwith header/footer templates. - Added an Appium-based UI test validating group header width matches the item/footer width.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| src/Controls/src/Core/Platform/Windows/CollectionView/ItemsViewStyles.xaml | Adjusts Windows header container defaults to allow group header templates to stretch full width. |
| src/Controls/tests/TestCases.HostApp/Issues/Issue23038.cs | Adds a grouped CollectionView scenario with header/footer templates and AutomationIds for testing. |
| src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue23038.cs | Adds an Appium UI test asserting header width stretches to match the CollectionView/item/footer width. |
🧪 PR Test EvaluationOverall Verdict: The UI test covers the primary fix scenario (list-based grouped CollectionView header stretching) but misses coverage for the grid-based layout path that the fix also modifies.
📊 Expand Full EvaluationPR Test Evaluation ReportPR: #34710 — Fix CollectionView group header not stretching to full width on Windows Overall VerdictThe test validates the primary fix (header stretching to full width in list-based CollectionView), but the fix also modifies 1. Fix Coverage — ✅The fix changes
The test creates a grouped Minor gap: the 2. Edge Cases & Gaps —
|
MauiBot
added
s/agent-changes-requested
🧪 PR Test EvaluationOverall Verdict: ✅ Tests are adequate The test directly validates the fix — it verifies that group headers stretch to the full CollectionView width on Windows, which is exactly what the XAML style change achieves.
📊 Expand Full EvaluationPR Test Evaluation ReportPR: #34710 — [Windows] CollectionView group header not stretching to full width Overall Verdict✅ Tests are adequate The test exercises the exact behavior fixed by the PR: it measures group header and footer widths to confirm the header now stretches to full CollectionView width, which directly reflects the 1. Fix Coverage — ✅The fix changes The test:
The test would fail without the fix (header stays 2. Edge Cases & Gaps —
|
| Fix | Test | |
|---|---|---|
| Control | ListViewHeaderItem / GridViewHeaderItem (Windows XAML) |
Grouped CollectionView header on Windows |
| Property | HorizontalContentAlignment: Left → Stretch |
Header width == full CollectionView width |
| Would fail without fix? | ✅ Yes — header stays narrow | ✅ Yes — headerRect.Width != footerRect.Width |
Recommendations
- (Optional) Add a second assertion for
HeaderTeamB/FooterTeamBto verify all groups are affected, not just the first. - (Optional) Consider a brief comment in the test explaining why the footer is used as the "full width" baseline — it's a non-obvious but correct approach.
- (Non-blocking) The
GridViewHeaderItemstyle fix is untested (no test usesItemsLayout = GridItemsLayout). Not strictly required since the root cause is the same, but worth noting.
Warning
⚠️ Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
dc.services.visualstudio.com
To allow these domains, add them to the network.allowed list in your workflow frontmatter:
network:
allowed:
- defaults
- "dc.services.visualstudio.com"See Network Configuration for more information.
Note
🔒 Integrity filtering filtered 1 item
Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.
- pr:Fix CollectionView group header not stretching to full width on Windows #34710 (
pull_request_read: Resource 'pr:Fix CollectionView group header not stretching to full width on Windows #34710' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)
🧪 Test evaluation by Evaluate PR Tests
🧪 PR Test EvaluationOverall Verdict: The test correctly validates the primary fix (list-layout group header stretching), but the fix also changes
📊 Expand Full EvaluationPR Test Evaluation ReportPR: #34710 — Fix CollectionView group header not stretching to full width on Windows Overall VerdictThe test adequately covers the default linear-layout case but the fix also changes 1. Fix Coverage — ✅The test directly measures 2. Edge Cases & Gaps —
|
🧪 PR Test EvaluationOverall Verdict: ✅ Tests are adequate The tests directly validate the fix by measuring element widths, covering both list and grid layout modes. Minor naming and platform-scope concerns don't block the fix.
📊 Expand Full EvaluationPR Test Evaluation ReportPR: #34710 — [Windows] GroupHeaderTemplate width smaller than ItemTemplate Overall Verdict✅ Tests are adequate Both tests directly measure group header width against item/footer width, which is precisely what the fix changes ( 1. Fix Coverage — ✅The fix changes two WinUI styles in
Both tests would fail if the fix were reverted (header would be narrower than footer due to 2. Edge Cases & Gaps —
|
| Finding | Assessment |
|---|---|
Issue23038_GridLayout does not follow IssueXXXXX naming |
Real concern — convention is IssueXXXXX only. Consider renaming to a separate issue number or using Issue23038 for both and splitting with test method names. The _GridLayout suffix is non-standard. |
HeaderTeamA, FooterTeamA AutomationIds not found in HostApp |
False positive — these are set via SetBinding(Label.AutomationIdProperty, "Key", stringFormat: "Header{0}") which produces "HeaderTeamA" at runtime. The script can't detect dynamic bindings. |
GridHeaderTeamA, GridFooterTeamA AutomationIds not found in HostApp |
False positive — same reason, dynamically bound. |
Genuine issues:
Issue23038_GridLayoutnaming violatesIssueXXXXXconvention (the guidelines state names should follow this pattern).
Looks good:
- ✅
[Issue()]attribute withPlatformAffected.UWPon both HostApp pages - ✅
[Category(UITestCategories.CollectionView)]— exactly one per test - ✅ Inherits
_IssuesUITest - ✅
WaitForElementused before all interactions - ✅ No
Task.Delay/Thread.Sleep - ✅ No inline
#ifplatform directives - ✅ No obsolete APIs
5. Flakiness Risk — ✅ Low
WaitForElementused for all elements beforeGetRect()— correctWithin(20)tolerance for CollectionView vs footer width (accounts for scrollbar) — appropriateWithin(2)tolerance for header vs footer (sub-pixel precision) — appropriate- No screenshot comparisons, no animation timing concerns
- No
Task.Delay/Thread.Sleepanti-patterns
6. Duplicate Coverage — ✅ No duplicates
The similar tests surfaced by the script (Issue12060, Issue13123, etc.) match on generic "Platform" keywords and are unrelated to CollectionView grouped layout width. No existing test covers GroupHeaderTemplate width stretching on Windows.
7. Platform Scope — ⚠️
The fix is Windows-only (WinUI ListViewHeaderItem/GridViewHeaderItem styles). The tests have no platform restriction — they will run on Android, iOS, and MacCatalyst as well.
Impact: On non-Windows platforms, the test should still pass (group headers already stretch to full width there), so this won't cause failures. However, it means unnecessary CI time on other platforms.
Recommendation: Consider adding #if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_IOS && TEST_FAILS_ON_MACCATALYST or a similar guard (following the pattern used in Issue16973.cs). Not blocking, but worth noting.
8. Assertion Quality — ✅
Assert.That(footerRect.Width, Is.EqualTo(collectionViewRect.Width).Within(20));
Assert.That(headerRect.Width, Is.EqualTo(footerRect.Width).Within(2));- First assertion validates footer (a
ListViewItem) stretches to the CollectionView width — establishes a reliable baseline - Second assertion validates header equals footer — directly tests that the fix's
HorizontalContentAlignment="Stretch"is working - Tolerances are justified and documented in comments
- Not brittle (no hardcoded pixel values)
9. Fix-Test Alignment — ✅
| Fix Change | Test Coverage |
|---|---|
ListViewHeaderItem → HorizontalContentAlignment: Stretch |
Issue23038 measures headerRect.Width == footerRect.Width |
GridViewHeaderItem → HorizontalContentAlignment: Stretch |
Issue23038_GridLayout measures same for grid mode |
ListViewHeaderItem → Padding: 0,0,0,0 |
Covered (padding affects effective width) |
GridViewHeaderItem → Padding: 0,0,0,0 |
Covered |
Recommendations
-
Rename
Issue23038_GridLayoutto followIssueXXXXXnaming convention. Since this is the same issue, the test could be renamed (e.g., keep both as separate test classes in one file, or open a second tracking issue). This is the only real convention violation. -
Consider adding platform guards to restrict these tests to Windows only (e.g., using
#ifpreprocessor guards followingIssue16973.cspattern). The fix is Windows-only and running on other platforms adds unnecessary CI overhead. -
Optionally assert TeamB headers as well to strengthen confidence that the fix applies to all groups (low priority — the fix is style-level and applies universally).
Warning
⚠️ Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
dc.services.visualstudio.com
To allow these domains, add them to the network.allowed list in your workflow frontmatter:
network:
allowed:
- defaults
- "dc.services.visualstudio.com"See Network Configuration for more information.
Note
🔒 Integrity filtering filtered 1 item
Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.
- pr:Fix CollectionView group header not stretching to full width on Windows #34710 (
pull_request_read: Resource 'pr:Fix CollectionView group header not stretching to full width on Windows #34710' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)
🧪 Test evaluation by Evaluate PR Tests
|
/azp run maui-pr-uitests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
🧪 PR Test EvaluationOverall Verdict: ✅ Tests are adequate The two UI tests directly verify the core fix effect (group headers stretching to full CollectionView width on Windows), covering both the standard list layout and the grid layout scenarios. Script-reported AutomationId warnings are false positives caused by dynamic data binding.
📊 Expand Full EvaluationPR Test Evaluation ReportPR: #34710 — Fix CollectionView group header not stretching to full width on Windows Overall Verdict✅ Tests are adequate Both UI tests directly verify the visual effect of the fix (header stretching to full width) and are appropriate in type for a Windows-specific layout fix requiring pixel-width measurement. 1. Fix Coverage — ✅The fix changes
The tests would fail if the fix were reverted.
2. Edge Cases & Gaps —
|
| Warning | Assessment |
|---|---|
AutomationId 'HeaderTeamA' not found in HostApp |
❌ False positive — Set via SetBinding(Label.AutomationIdProperty, nameof(Key), stringFormat: "Header{0}") → resolves to "HeaderTeamA" at runtime |
AutomationId 'FooterTeamA' not found in HostApp |
❌ False positive — Same dynamic binding pattern |
AutomationId 'GridHeaderTeamA' not found in HostApp |
❌ False positive — Same dynamic binding pattern |
Issue23038_GridLayout name doesn't follow IssueXXXXX pattern |
Naming convention (Issue23038_GridLayout):
The _GridLayout suffix on both HostApp and test files is non-standard. However, the HostApp class correctly uses [Issue(..., issueTestNumber: 1)] which is the proper mechanism for multiple test pages per issue. The naming is consistent between HostApp and NUnit test. This is a minor deviation — the suffix is descriptive but doesn't follow the convention strictly.
Everything else is compliant:
- ✅
_IssuesUITestbase class - ✅
[Issue()]attribute with correctPlatformAffected.UWP - ✅ Exactly one
[Category(UITestCategories.CollectionView)]per test - ✅
WaitForElementbefore allGetRect()calls - ✅ No
Task.Delay/Thread.Sleep - ✅ No inline
#ifdirectives - ✅ No obsolete APIs
5. Flakiness Risk — ✅ Low
- Tests use
GetRect()for width comparison — not screenshot-based, so no cursor-blink risk WaitForElementis used before every element access- Tolerances are justified:
Within(20)accounts for Windows scrollbar width;Within(2)for header vs footer comparison is tight but reasonable - Assertions are relative (element width vs other element width), not absolute pixel values — more robust across display scaling
6. Duplicate Coverage — ✅ No duplicates
No existing tests cover CollectionView grouped layout header width on Windows. The script results showing Issue12060, Issue13123, etc., are unrelated (matched on Platform keyword, not CollectionView grouped headers).
7. Platform Scope — ✅
The fix is in Platform/Windows/CollectionView/ItemsViewStyles.xaml — Windows-only. Both HostApp tests correctly set PlatformAffected.UWP. Tests will be skipped on Android/iOS/Mac automatically.
8. Assertion Quality — ✅
| Assertion | Quality |
|---|---|
footerRect.Width ≈ collectionViewRect.Width (±20) |
✅ Specific, justified tolerance (scrollbar) |
headerRect.Width ≈ footerRect.Width (±2) |
✅ Tight, specific, meaningful |
headerRect.Width ≈ collectionViewRect.Width (±20) |
✅ Specific, same justified tolerance |
All assertions would catch a regression if HorizontalContentAlignment were reverted to Left.
9. Fix-Test Alignment — ✅
- Fix:
ListViewHeaderItem→HorizontalContentAlignment=Stretch+ zero padding - Test 1 (
Issue23038): Standard list CollectionView → verifies header width matches footer (full-width stretch) ✅ - Fix:
GridViewHeaderItem→ same changes - Test 2 (
Issue23038_GridLayout): Grid CollectionView → verifies header spans full width ✅
Both test/fix pairs are aligned.
Recommendations
- Minor: Rename
Issue23038_GridLayoutfiles to a convention-compliant name if the team's naming standards require strictIssueXXXXXformat. TheissueTestNumber: 1attribute is correct; the file name deviation is cosmetic. - Optional: Add an assertion that
headerRect.X == 0(or very close to 0) to verify the padding change (left indent removed). This would catch if the padding were reverted independently of the alignment. - Note: The script's AutomationId warnings (
HeaderTeamA,FooterTeamA,GridHeaderTeamA) are false positives — all three are set via dynamicSetBindingand will resolve correctly at runtime.
Warning
⚠️ Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
dc.services.visualstudio.com
To allow these domains, add them to the network.allowed list in your workflow frontmatter:
network:
allowed:
- defaults
- "dc.services.visualstudio.com"See Network Configuration for more information.
Note
🔒 Integrity filtering filtered 1 item
Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.
- pr:Fix CollectionView group header not stretching to full width on Windows #34710 (
pull_request_read: Resource 'pr:Fix CollectionView group header not stretching to full width on Windows #34710' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)
🧪 Test evaluation by Evaluate PR Tests
MauiBot
added
s/agent-approved
|
/azp run maui-pr-uitests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
🔍 Multi-Reviewer Code Review — PR #34710 Fix CollectionView group header not stretching to full width on Windows CI Status: ✅ All 35 checks passing Prior Review Comments: None (bot comments only) --- ### 🔴 CRITICAL 1. Breaking change ships without a compatibility guard (3/3 reviewers agreed) - File:
|
|
| Property | Before | After |
|---|---|---|
Padding |
12,8,12,0 |
0,0,0,0 |
HorizontalContentAlignment |
Left |
Stretch |
This IS a visual breaking change for existing Windows apps
Who is affected:
- Apps using grouped
CollectionViewon Windows that rely on the default container padding for group headers. These apps will see headers shift from having 12px side padding + 8px top padding with left-alignment to zero padding with full-width stretch.
Who is NOT affected:
- Apps with custom
GroupHeaderTemplatethat set their ownPaddingandHorizontalOptionson the template root element — these already control their own spacing and will be unaffected. - Apps on Android, iOS, and macOS — this change is Windows-only (
ListViewHeaderItem/GridViewHeaderItemare WinUI container types).
Question for MAUI team
Does this need a compatibility switch (AppContext flag) or should it be gated to net11.0 TFM? The PR author raised this question in the description — would appreciate guidance on the preferred approach.
Also pushed commit 075b56cc71 adding FailsOnAndroid/iOS/Mac platform guards to both UI test methods so they only run on Windows.
|
@rmarinho the change looks good! I've changed the base to net11 - I agree that it is a breaking change, so it will be safer to include it in net11 |
rmarinho
dismissed
kubaflo’s stale review
The merge-base changed after approval.
- Community PR: replaced PR #35144 (got closed during eval) with PR #34710 (older, stable state). Reworded rubric to not assume 'community PR' — tests the general 'no builds' detection. - Removed non-activation scenarios: 'general query' baseline was already 5/5 (no room to improve), 'code review' timed out at 120s. These dragged the improvement score negative. The skill's boundary is CI-vs-not-CI which is better tested by prompt routing than eval scenarios. - Kept 3 positive scenarios that showed real improvement (+1.0 and +2.3 in the first eval run). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@copilot can you rebase this on top of net11.0 branch please |
Done — merged net11.0 into the branch (commit |
|
/review |
|
✅ Expert Code Review completed successfully! |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Expert Code Review — PR #34710
Methodology: 3 independent reviewers with adversarial consensus (findings only included when 2+ reviewers agree on the same root cause).
Findings Summary
| # | Severity | Finding | Consensus |
|---|---|---|---|
| 1 | Breaking visual change — branch targeting unresolved | 3/3 reviewers | |
| 2 | Test coverage gap for non-group header scenarios | 3/3 reviewers | |
| 3 | 💡 MINOR | New tests should include VerifyScreenshot() |
3/3 reviewers (after follow-up) |
| 4 | 💡 MINOR | MinHeight + zero padding interaction worth documenting | 2/3 reviewers |
Key Decision Point
The primary open question is branch targeting. The author correctly identifies this as a potential breaking change. All 3 reviewers independently flagged this as the most important unresolved item:
- Removing implicit
12,8,12,0container padding changes visual appearance for every Windows app using grouped CollectionView without explicit padding inGroupHeaderTemplate - The style is implicit (no
x:Key), so it applies globally to allListViewHeaderItem/GridViewHeaderIteminstances
A maintainer decision is needed: Is the old Left alignment a bug (fix on main/net11.0) or is the new Stretch behavior a deliberate breaking change (requiring release notes)?
Discarded Findings (single reviewer, not confirmed)
Snapshot baselines need cross-platform verification— Both follow-up reviewers noted the change is Windows-only; cross-platform drift is not mechanically possibleNo gallery sample added— Discarded (single reviewer, lowest severity)
CI & Test Coverage Assessment
The PR includes 2 new UI test pages and 2 corresponding NUnit test files covering both linear and grid layout scenarios. 9 existing Windows snapshot baselines were updated to reflect the new visual appearance. The tests validate the fix target (grouped headers stretching) but lack coverage for adjacent scenarios (non-grouped headers, virtualized containers).
Verdict: NEEDS_DISCUSSION
Confidence: High
The XAML fix is mechanically correct and well-tested for its stated purpose. The outstanding blocker is the unresolved breaking-change question. Once a maintainer confirms the branch target, the secondary items (test coverage gaps, VerifyScreenshot) should be straightforward to address.
Generated by Expert Code Review for issue #34710 · ● 10.6M
| <Setter Property="Padding" Value="0,0,0,0" /> | ||
| <Setter Property="HorizontalContentAlignment" Value="Stretch" /> |
There was a problem hiding this comment.
Removing the 12,8,12,0 padding and switching to HorizontalContentAlignment="Stretch" is a silent visual regression for existing Windows apps that rely on the implicit container padding. Group header labels that previously had 12px of breathing room will now abut the container edge.
The author correctly flags this as a breaking change, but the PR currently targets net11.0. Per MAUI branching conventions, main is for non-breaking fixes and the highest netN.0 branch is for behavioral changes. The question is whether the old Left alignment is treated as a bug (fixable on main) or the new behavior is a deliberate breaking change (requiring a major release).
Recommendation: A maintainer should explicitly decide the branch target and, if this ships as-is, add a BREAKING_CHANGE marker to the release notes so adopters are aware their headers will lose the built-in padding.
| [Category(UITestCategories.CollectionView)] | ||
| [FailsOnAndroidWhenRunningOnXamarinUITest("Windows-only test: validates WinUI CollectionView group header styles")] | ||
| [FailsOnIOSWhenRunningOnXamarinUITest("Windows-only test: validates WinUI CollectionView group header styles")] | ||
| [FailsOnMacWhenRunningOnXamarinUITest("Windows-only test: validates WinUI CollectionView group header styles")] | ||
| public void GroupHeaderShouldStretchToFullWidth() |
There was a problem hiding this comment.
The ListViewHeaderItem/GridViewHeaderItem styles are implicit (no x:Key), so the padding and alignment changes affect all headers using those container types — not only group headers. This includes the top-level CollectionView.Header on Windows.
The tests validate grouped-header stretching (which is the fix target), but there is no regression guard for:
- Regular (non-grouped)
CollectionView.Headerbehavior — does it still render correctly with zero container padding? - Virtualized group headers that enter the viewport after scrolling (container recycling edge case)
Recommendation: Add a companion test (or assertion within an existing test) that verifies a non-grouped CollectionView with a Header property still renders correctly on Windows after this change.
| "Group header should render at or below the CollectionView top edge"); | ||
| Assert.That(headerARect.Y, Is.LessThan(footerARect.Y), | ||
| "Group header should render above its group footer"); | ||
| } |
There was a problem hiding this comment.
💡 Consider adding VerifyScreenshot() for visual regression protection (3/3 reviewers after follow-up)
GetRect() assertions validate layout metrics but won't catch visual regressions like content clipping at the new zero-padding boundary or rendering artifacts. Since this PR already updates 9 existing Windows snapshot baselines (proving the visual output changed), adding VerifyScreenshot() here would establish a baseline for the new expected appearance.
VerifyScreenshot(retryTimeout: TimeSpan.FromSeconds(2));| <Setter Property="Padding" Value="0,0,0,0" /> | ||
| <Setter Property="HorizontalContentAlignment" Value="Stretch" /> | ||
| <Setter Property="VerticalContentAlignment" Value="Top" /> | ||
| <Setter Property="MinHeight" Value="{ThemeResource ListViewHeaderItemMinHeight}" /> |
There was a problem hiding this comment.
💡 MinHeight + zero padding interaction (2/3 reviewers)
MinHeight is still bound to {ThemeResource ListViewHeaderItemMinHeight}. With the old 8px top padding, content was offset downward and the effective content area was MinHeight - 8. Now with zero padding and VerticalContentAlignment="Top", a header template smaller than MinHeight will have visible empty space below the content (previously the dead space was above/around it).
This is likely acceptable — the PR's intent is to hand layout control to the template — but worth noting in the PR description so adopters understand the full visual impact.
|
/review -b feature/refactor-copilot-yml |
The ListViewHeaderItem and GridViewHeaderItem styles in ItemsViewStyles.xaml had HorizontalContentAlignment set to Left and Padding of 12,8,12,0 which prevented group headers from stretching to match item width. Changed to HorizontalContentAlignment=Stretch with zero padding to match how regular item containers are configured. Preserved the 4px bottom margin for visual separation between headers and items. Fixes #23038 Fixes #16824 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…lish - Revert MinHeight to theme resources for ListViewHeaderItem and GridViewHeaderItem (unrelated to the stretching fix) - Use PascalCase AutomationIds without spaces for group headers/footers by adding a Key property to the team model - Update XAML comments to reflect full scope of style customizations - Remove redundant WaitForElement call and add tolerance explanation - Update UI test to reference the sanitized AutomationIds Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Cover the GridViewHeaderItem style change with a test that uses GridItemsLayout(2, Vertical) and verifies group headers stretch to full CollectionView width in grid mode. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… footers - Add issueTestNumber:1 to Issue23038_GridLayout to avoid duplicate DisplayName conflict with Issue23038 (both had 'G23038') - Fix grid test assertion: in GridItemsLayout, group footers are regular grid items that span one column, not full width. Compare header directly to CollectionView width instead. - Both tests verified passing locally on Windows via Appium UI tests Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add FailsOn*WhenRunningOnXamarinUITest attributes to both Issue23038 and Issue23038_GridLayout test methods so they are skipped on Android, iOS, and Mac. These tests validate WinUI-specific CollectionView group header styles and should only run on Windows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…tyle changes Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add direct header-vs-CollectionView width assertion in list test (primary) - Assert on both TeamA and TeamB groups to catch virtualization regressions - Widen header-vs-footer tolerance from 2px to 5px for DPI safety - Add vertical-spacing sanity assertions (header within CV, above footer) - Fix nameof() inconsistency in Issue23038_GridLayout.cs host app Addresses findings #8-#12 from PR review. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
rmarinho
force-pushed
the
fix/collectionview-group-header-width-23038
branch
from
6481b22 to
31ced80
Compare
|
/review -b feature/refactor-copilot-yml -p windows |
Description of Change
The ListViewHeaderItem and GridViewHeaderItem styles in ItemsViewStyles.xaml had HorizontalContentAlignment set to Left and Padding of 12,8,12,0 which prevented group headers from stretching to match item width.
Changed to HorizontalContentAlignment=Stretch with zero padding to match how regular item containers are configured. Preserved the 4px bottom margin for visual separation between headers and items.
As this is a breaking change i think we might want to net11.0 ?
Issues Fixed
Fixes #23038
Fixes #16824