[Windows] Fix CollectionView ScrollTo related test cases failed in CI

[HarishwaranVijayakumar]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root Cause

• PR 24867 fixed a COM exception on Windows by wrapping ListViewBase.ScrollIntoView inside DispatcherQueue.TryEnqueue() in ItemsViewHandler.Windows.cs → OnItemsVectorChanged. This changed ScrollIntoView from synchronous to asynchronous execution, introducing a race condition in ScrollTo-related UI tests on Windows.

• Before 24867

  • Items load → OnItemsVectorChanged → ScrollIntoView fires (sync) → Scrolled event updates label → Test resets label → Label = "Not Fired"

• After 24867 (async via TryEnqueue):

  • Items load → OnItemsVectorChanged → ScrollIntoView is queued (async) → Test resets label to "Not Fired" → Queued ScrollIntoView fires → Scrolled event overwrites label = "Fired"

• The deferred ScrollIntoView callback executes after the test has already reset the scroll event labels, causing stale scroll events to overwrite the expected state. Similarly, for ScrollTo(animate: true) tests, the animated scroll produces intermediate Scrolled events that haven't settled to the final index when the test reads the label value.

Description of Change

Test reliability improvements:

• Added a delay in CollectionViewScrollPage.xaml.cs before resetting scroll event labels to ensure deferred callbacks complete, preventing test flakiness on Windows.
• Disabled animation for ScrollTo actions on Windows in Issue33614.cs to avoid flaky test results.

Test coverage and platform-specific adjustments:

• Removed Windows-specific test skip conditions in Issue33614.cs and CollectionView_ScrollingFeatureTests.cs, re-enabling these tests on Windows as the related issues have been resolved. [1] [2] [3] [4]
• Updated conditional compilation for a grouped list test to only skip on Android, as the Windows issue has been addressed.

Issues Fixed

Fixes #34772

Before	After

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34907

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34907"

[dotnet-policy-service]

Hey there @@HarishwaranVijayakumar! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull request overview

Improves Windows CI reliability for CollectionView ScrollTo-related UI tests that became flaky after ScrollIntoView started running asynchronously on Windows (via DispatcherQueue.TryEnqueue).

Changes:

• Re-enabled previously skipped Windows UI tests for CollectionView scrolling/ScrollTo scenarios.
• Added a delay before resetting scroll event labels on the scrolling feature-matrix page to avoid deferred scroll callbacks overwriting the reset state.
• Disabled animated ScrollTo on Windows for Issue33614’s HostApp page to reduce timing-related flakiness.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33614.cs	Removes Windows-only compilation guard so the Issue33614 UI test runs on Windows again.
src/Controls/tests/TestCases.Shared.Tests/Tests/FeatureMatrix/CollectionView_ScrollingFeatureTests.cs	Removes/relaxes Windows skip conditions so ScrollTo-related feature-matrix tests run on Windows.
src/Controls/tests/TestCases.HostApp/Issues/Issue33614.cs	Makes Issue33614’s ScrollTo non-animated on Windows to reduce flaky timing in the HostApp scenario.
src/Controls/tests/TestCases.HostApp/FeatureMatrix/CollectionView/ScrollingFeature/CollectionViewScrollPage.xaml.cs	Adds an awaitable delay before resetting scroll event labels to avoid deferred Windows callbacks overwriting expected label state.

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[kubaflo]

Could you please review ai's suggestions

[MauiBot]

🤖 AI Summary

👋 @HarishwaranVijayakumar — new AI review results are available. Please review the latest session below.

📊 Review Session — db23dc8 · Address copilot concern · 2026-04-26 12:03 UTC

---

🚦 Gate — Test Before & After Fix

---

Gate Result: ❌ FAILED

Platform: ANDROID

Gate output log

No PR detected, scanning remote branches for closest base...
✅ Base branch: main (via closest-merge-base)
✅ Merge base commit: 857e11c0
   (2 commits ahead of main)
╔═══════════════════════════════════════════════════════════╗
║         ERROR: NO FIX FILES DETECTED                      ║
╠═══════════════════════════════════════════════════════════╣
║  Full verification mode required but no fix files found.  ║
║                                                           ║
║  Possible causes:                                         ║
║  - No non-test files changed since merge-base             ║
║  - All changes are in test directories                    ║
╚═══════════════════════════════════════════════════════════╝
Debug info:
  Merge base: 857e11c0c4b1c4963f56aaa0c576b1625d1cf4ff
  Base branch: main
  Current branch: HEAD
To fix, try one of:
  1. Specify fix files explicitly: -FixFiles @('path/to/fix.cs')
  2. Remove -RequireFullVerification to run in failure-only mode

---

🧪 UI Tests — Category Detection

---

Detected UI test categories: CollectionView

---

🔍 Pre-Flight — Context & Validation

---

Issue: #34772 - [Testing][Windows]CollectionView ScrollTo related test cases failed in CI
PR: #34907 - [Windows] Fix CollectionView ScrollTo related test cases failed in CI
Platforms Affected: Windows (test reliability fix; gate run on Android)
Files Changed: 0 implementation, 4 test

Key Findings

• All changes are test-only: no production source files modified
• Root cause: PR [Windows] Fixed CollectionView with grouping fails to add items when a footer template is present or crashes when removing data. #24867 wrapped ListViewBase.ScrollIntoView inside DispatcherQueue.TryEnqueue() in ItemsViewHandler.Windows.cs, making it async — introducing a race condition where test label resets happen before deferred callbacks fire
• Fix adds await Task.Delay(300) on Windows in CollectionViewScrollPage.xaml.cs before ResetScrollEventLabels() to let deferred callbacks complete
• Fix disables animation for ScrollTo on Windows in Issue33614.cs to avoid flaky intermediate scroll events
• Removes TEST_FAILS_ON_WINDOWS guards from CollectionView_ScrollingFeatureTests.cs and Issue33614.cs tests
• Gate ❌ FAILED with "NO FIX FILES DETECTED" — expected because this is a test-only PR (no non-test source files changed)
• Prior Copilot inline review flagged Task.Delay(300) as potentially flaky; author marked as "Addressed" — but delay remains in current code
• PR has prior s/agent-changes-requested and s/agent-fix-win labels from a previous agent run

Code Review Summary

Verdict: LGTM
Confidence: high
Errors: 0 | Warnings: 1 | Suggestions: 2

Key code review findings:

• ⚠️ CollectionViewScrollPage.xaml.cs:25 — Task.Delay(300) could be reduced to Task.Delay(0) or Task.Yield() for dispatcher-flush semantics (functionally correct but slower and marginally more fragile)
• 💡 Issue33614.cs:5 — PlatformAffected attribute still only lists iOS | macOS despite now having Windows-specific code
• 💡 Issue33614.cs:75 — trailing whitespace in comment

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34907	Test-only: add Task.Delay(300) on Windows before label reset + disable animation on Windows for Issue33614 + remove TEST_FAILS_ON_WINDOWS guards	⏳ PENDING (Gate failed: test-only PR, no fix files)	CollectionViewScrollPage.xaml.cs, Issue33614.cs, CollectionView_ScrollingFeatureTests.cs, Issue33614.cs (tests)	Original PR

---

🔬 Code Review — Deep Analysis

---

Code Review — PR #34907

Independent Assessment

What this changes: Four files, all in the test layer:

1. A #if WINDOWS Task.Delay(300) in NavigateToOptionsPage_Clicked before ResetScrollEventLabels() in HostApp
2. A #if WINDOWS switch from animate: true → animate: false in Issue33614's scroll button handler
3. Removal of TEST_FAILS_ON_WINDOWS guards from the Issue33614 UI test class
4. Narrowing #if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_WINDOWS → #if TEST_FAILS_ON_ANDROID on VerifyKeepScrollOffsetWithObservableList
5. Removal of #if TEST_FAILS_ON_WINDOWS block guarding VerifyScrollToByIndexWithMakeVisiblePositionAndVerticalList_Carrot and following ScrollTo tests

Inferred motivation: Windows CollectionView ScrollTo tests were racing against async scroll triggered by items loading. PR #24867 wrapped ListViewBase.ScrollIntoView in DispatcherQueue.TryEnqueue(), making the initial auto-scroll deferred — labels get reset before the deferred callback fires, then overwritten.

---

Reconciliation with PR Narrative

Agreement: Root cause analysis precisely matches the code. The Task.Delay(300) lets the dispatcher queue flush before label reset. The animate: false avoids intermediate Scrolled events from animation that would set a non-final FirstVisibleItemIndex when the test reads it. Both are technically sound workarounds.

---

Findings

⚠️ Warning — Task.Delay(300) may be larger than necessary and risks future flakiness

File: CollectionViewScrollPage.xaml.cs:25

#if WINDOWS
    await Task.Delay(300);
#endif

On WinUI, await checkpoints yield control back to the DispatcherQueue, meaning the enqueued callback will process when the await completes — not after 300ms of wall-clock time. This means await Task.Delay(0) (or await Task.Yield()) would achieve the same flush semantics.

The 300ms:

1. Adds 300ms to every test that navigates through this page on Windows
2. Doesn't provide stronger guarantees than Task.Delay(0) for the stated use case
3. Could theoretically fail on a severely degraded CI machine

Recommendation: await Task.Delay(0) or await Task.Yield() for semantically clearer, faster, equally correct behavior.

💡 Suggestion — [Issue] attribute PlatformAffected doesn't reflect Windows coverage

File: src/Controls/tests/TestCases.HostApp/Issues/Issue33614.cs:5

[Issue(IssueTracker.Github, 33614, "...", PlatformAffected.iOS | PlatformAffected.macOS)]

This HostApp page now includes Windows-specific code. The PlatformAffected annotation should be updated to include Windows.

💡 Suggestion — Trailing space in comment

File: src/Controls/tests/TestCases.HostApp/Issues/Issue33614.cs:75

// Disable animation on Windows to avoid flaky test results 

Minor trailing whitespace.

---

Blast Radius

Scope: Test files only. No production code path affected. No handler, renderer, or platform layer changed.

Impacted test categories: CollectionView, ScrollView (indirectly)

Failure modes:

• Task.Delay(300) not long enough → scrolledEventLabel.Text = "Fired" when test expects "Not Fired" → test fails obviously (no silent pass risk)
• Animation disabled on Windows for Issue33614 → reduces coverage of animated-scroll path on Windows (known accepted trade-off)

---

Verdict: LGTM

Confidence: high

Summary: Pure test-layer fix. Removes Windows skip guards and adds targeted workarounds for known Windows async dispatch behavior. Task.Delay(300) could be Task.Delay(0) for equivalent correctness and faster tests, and PlatformAffected should include Windows, but neither is a blocking issue. No production code changed.

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Replace Task.Delay(300) with Task.Yield() for dispatcher-flush semantics	⚠️ BLOCKED	CollectionViewScrollPage.xaml.cs, Issue33614.cs, test files	Test-only PR, no fix files for baseline script
2	try-fix (claude-sonnet-4.6)	DispatcherQueue.TryEnqueue(Low priority) + TaskCompletionSource for deterministic flush	⚠️ BLOCKED	CollectionViewScrollPage.xaml.cs, Issue33614.cs	Test-only PR, deterministic but cannot be tested
3	try-fix (gpt-5.3-codex)	Deterministic label polling in UI test assertions; remove animate:false	⚠️ BLOCKED	All 4 test files	Test-only PR, Windows UI tests cannot run on Android agent
4	try-fix (gpt-5.4)	Production code fix in ItemsViewHandler.Windows.cs — suppress auto-scroll when ListViewBase.IsLoaded is false	⚠️ BLOCKED	ItemsViewHandler.Windows.cs	Only attempt targeting production code; cannot run Windows UI tests on Android
PR	PR #34907	Test-only: Task.Delay(300) on Windows before label reset + animate:false on Windows + remove TEST_FAILS_ON_WINDOWS guards	❌ Gate FAILED (test-only, no fix files detected)	4 test files	Original PR

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	No	All approaches identified correctly. Attempt 4 (production code fix in ItemsViewHandler.Windows.cs) is the right direction but needs Windows agent.

Exhausted: Yes
Selected Fix: PR's fix — No test-executable alternative found (all blocked due to test-only PR + Android-only agent). PR's test-only approach is the pragmatic choice and code review rated LGTM.

Notes

• All try-fix attempts were BLOCKED because: (1) this is a test-only PR with no non-test source files changed, so EstablishBrokenBaseline.ps1 cannot establish a broken baseline; (2) the target platform is Android but the issue and tests are Windows-specific
• Attempt 4 proposed a potentially stronger production code fix in ItemsViewHandler.Windows.cs that would eliminate the root cause entirely, but cannot be empirically tested on this agent

---

📋 Report — Final Recommendation

---

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Test-only PR, issue #34772, Windows CollectionView ScrollTo flakiness
Code Review	LGTM (high)	0 errors, 1 warning, 2 suggestions
Gate	❌ FAILED	Android — "No fix files detected" (expected: test-only PR)
Try-Fix	✅ COMPLETE	4 attempts, 0 passing (all BLOCKED: test-only + Android agent)
Report	✅ COMPLETE

Code Review Impact on Try-Fix

The code review ⚠️ Warning about Task.Delay(300) being replaceable with Task.Yield() or Task.Delay(0) was reflected in Attempts 1 and 2, which explored Task.Yield() and a DispatcherQueue.TryEnqueue(Low) + TaskCompletionSource flush respectively. Attempt 4 (gpt-5.4) went further and proposed a production-code fix in ItemsViewHandler.Windows.cs to eliminate the root cause entirely. The code review finding guided all models toward more deterministic synchronization approaches.

Summary

PR #34907 is a test-only fix for Windows CollectionView ScrollTo flakiness caused by PR #24867's async DispatcherQueue.TryEnqueue wrapper. The fix is pragmatically sound: a Task.Delay(300) to allow deferred callbacks to complete before resetting labels, animate:false on Windows to avoid intermediate scroll events, and removal of TEST_FAILS_ON_WINDOWS guards. Code review rated LGTM with one warning.

Recommendation is REQUEST CHANGES for the following reasons:

1. Gate failed — tests did not behave as expected (per prompt). While the gate failure is due to a test-only PR detection issue (not actual test failures), the gate outcome is ❌ FAILED.
2. Stronger alternative identified — Try-Fix Attempt 4 proposed a production-code fix in ItemsViewHandler.Windows.cs that would suppress the auto-scroll on pre-load item population (!ListViewBase.IsLoaded). This would fix the root cause instead of working around it in tests, and would benefit all users — not just test reliability.
3. Task.Delay(300) is fragile — The 300ms arbitrary delay could be replaced with Task.Delay(0) or a DispatcherQueue.TryEnqueue(Low) flush for equivalent correctness. As noted by Copilot's inline review comment (which the author dismissed), the timing-based approach may still be flaky on heavily loaded CI machines.

Root Cause

PR #24867 changed ScrollIntoView in OnItemsVectorChanged from synchronous to asynchronous via DispatcherQueue.TryEnqueue() on Windows. This introduced a race: when a test navigates to the scroll page, items load → OnItemsVectorChanged fires → ScrollIntoView is queued async → test code resets labels → queued scroll fires → labels overwritten with "Fired" instead of "Not Fired".

Fix Quality

The PR's test-layer fix is reasonable and pragmatic for immediate CI stabilization. However:

• Task.Delay(300) is an arbitrary timing heuristic — it works in practice but could silently become flaky if CI machines are slower, or waste 300ms when Task.Delay(0) would be sufficient
• Disabling animation on Windows for Issue33614 reduces test coverage of the animated scroll path (this concern was raised by Copilot inline review but dismissed by the author)
• Attempt 4's !ListViewBase.IsLoaded check in ItemsViewHandler.Windows.cs offers a cleaner production-code fix that would make the test-layer workarounds unnecessary

Suggested improvements:

1. Replace await Task.Delay(300) with await Task.Delay(0) (dispatcher flush) or a deterministic DispatcherQueue-based flush helper
2. Consider the production code fix: in ItemsViewHandler.Windows.cs OnItemsVectorChanged, capture !ListViewBase.IsLoaded before TryEnqueue and skip ScrollIntoView if true
3. Update PlatformAffected in Issue33614's [Issue] attribute to include PlatformAffected.Windows

---