ScrollView's ScrollToAsync doesn't complete when called thrice with the same value

[KarthikRajaKalaimani]

Issue Details:

When calling ScrollToAsync thrice with the same Y value on a ScrollView, the scrolling operation does not complete on iOS, Windows, and Catalyst platforms. This behavior is inconsistent with Android, where the scrolling operation completes as expected.

Root Cause:

The ScrollToAsync method does not mark the task as completed because the scroll did not occur due to the target position already being the current position. As a result, the ScrollToAsync method does not return control to the calling method.

Description of Change:

To resolve the issue, i called the ScrollFinished method if the target scroll position and current scroll position is same because the ScrollFinished method will mark the task as completed.

Tested the behavior in the following platforms.

• Android
• Windows
• iOS
• Mac

Reference:

N/A

Issues Fixed:

Fixes #27250

Screenshots

Before	After
Before_27250.mov	After_27250.mov

[KarthikRajaKalaimani]

@dotnet-policy-service agree company="Syncfusion, Inc."

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[EmilienDup]

Hi guys,

Any update on this PR?
We are also impacted by those never ending scrolling tasks.

Thank you.

[jsuarezruiz]

/rebase

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/rebase

[PureWeen]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Test case enabled for this issue · ce1d567

---

Problem: When calling ScrollToAsync thrice with the same Y value on a ScrollView, the scrolling operation does not complete on iOS, Windows, and Catalyst platforms. This behavior is inconsistent with Android, where the scrolling operation completes as expected.

Root Cause (from PR): The ScrollToAsync method does not mark the task as completed because the scroll did not occur due to the target position already being the current position. As a result, the ScrollToAsync method does not return control to the calling method.

Steps to Reproduce:

1. Launch the Application
2. Tap "Scroll to 100" twice and observe that the scrolling operation does not complete on MacCatalyst, iOS, and Windows.

Platforms Affected:

• iOS
• Android (works correctly)
• Windows
• MacCatalyst

---

🧪 Tests — Verification

---

📝 Review Session — Test case enabled for this issue · ce1d567

---

Status: ✅ COMPLETE

• PR includes UI tests (existing test ScrollToYTwice)
• Tests reproduce the issue
• Tests follow naming convention
• Tests compile successfully

Test Files:

• NUnit: src/Controls/tests/TestCases.Shared.Tests/Tests/ScrollViewUITests.cs - ScrollToYTwice() method

Test Logic:
The existing ScrollToYTwice() test:

1. Waits for "WaitForStubControl" element
2. Taps "Scroll100" button
3. Waits for "completed" label (task completion)
4. Taps "Scroll100" again
5. Waits for "completed" label again

The PR removes the FailsOnIOSWhenRunningOnXamarinUITest, FailsOnMacWhenRunningOnXamarinUITest, and FailsOnWindowsWhenRunningOnXamarinUITest attributes, indicating the fix enables the test to pass.

---

🚦 Gate — Test Verification

---

📝 Review Session — Test case enabled for this issue · ce1d567

---

Status: ✅ PASSED

• Tests FAIL without fix (bug reproduced)
• Tests PASS with fix

Platform Tested: Windows

Verification Results:

Phase	Status	Details
Revert Fix	✅	2 fix files reverted to merge-base state
Test WITHOUT Fix	✅ FAILED	Tests fail as expected - TimeoutException waiting for "completed" element
Restore Fix	✅	2 fix files restored from HEAD
Test WITH Fix	✅ PASSED	Tests pass with the fix applied (17 seconds)

Result: VERIFICATION PASSED ✅

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Test case enabled for this issue · ce1d567

---

Status: ✅ COMPLETE

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #27300	Post-dispatch check - call ScrollFinished() after native scroll if at target	✅ PASS (Gate)	2 files (handlers)	Original PR
1	try-fix	Pre-flight check in handlers BEFORE native scroll	✅ PASS	2 files (handlers)	Check before ChangeView/SetContentOffset
2	try-fix	Shared control layer pre-check in ScrollView.cs	✅ PASS	1 file (shared)	SIMPLEST: 7 lines, single file
3	try-fix	Use ChangeView() return value (Windows)	✅ PASS	1 file (Windows only)	Windows-specific only
4	try-fix	Delayed fallback dispatch with tolerance	❌ FAIL	1 file (shared)	Timeout - too late to complete
5	try-fix	Post-dispatch immediate position check	✅ PASS	2 files (handlers)	Same as PR's approach
6	try-fix	Coalesce duplicate requests with caching	✅ PASS	1 file (shared)	Complex - 33+ lines added

Cross-Pollination Results (Round 2):

Model	Response
claude-sonnet-4.5	NO NEW IDEAS
claude-opus-4.5	NO NEW IDEAS
gpt-5.2	NEW IDEA: Jiggle scroll (tested - not worth pursuing)
gpt-5.2-codex	NEW IDEA: Coalesce requests (tested as #6 - ✅ PASS)
gemini-3-pro-preview	NEW IDEA: Timeout wrapper (similar to failed #4)

Exhausted: Yes - 6 approaches tested, 5 passing, remaining ideas are less clean than existing solutions

Selected Fix: PR's fix (same as #5)

Rationale for Selection:
While Attempt #2 (shared layer pre-check) is the simplest (7 lines, single file), the PR's approach is:

1. Already implemented and tested across all affected platforms
2. Follows the existing code pattern (post-dispatch check)
3. More defensive - checks actual platform state after native call
4. Has been reviewed and rebased multiple times

The PR's fix is correct, minimal, and follows established patterns. No changes requested.

---

📋 Report — Final Recommendation

---

📝 Review Session — Test case enabled for this issue · ce1d567

---

Status: ✅ COMPLETE

Root Cause

When ScrollToAsync is called with coordinates that match the current scroll position, the native platform controls (ScrollViewer.ChangeView on Windows, UIScrollView.SetContentOffset on iOS) treat this as a no-op and don't fire their scroll completion events. Since MAUI's ScrollToAsync relies on these events to signal completion via ScrollFinished(), the returned Task never completes.

Fix Analysis

The PR correctly addresses this by checking if the scroll position matches the target position and explicitly calling ScrollFinished() when no scroll will occur:

• Windows: After calling ChangeView(), checks if offsets match and calls ScrollFinished()
• iOS: Extends the existing request.Instant condition to also check if already at target position

Alternative Approaches Tested

Approach	Result	Comparison to PR
Pre-flight check in handlers	✅ PASS	Similar complexity, less defensive
Shared layer check in ScrollView.cs	✅ PASS	Simpler (7 lines, 1 file) but different pattern
ChangeView() return value	✅ PASS	Windows-only, not cross-platform
Request coalescing	✅ PASS	More complex (33+ lines)

Recommendation

✅ APPROVE - The PR's fix is correct, minimal, and follows established patterns in the codebase. While a simpler alternative exists (shared layer check), the PR's approach is more defensive by checking actual platform state after the native call.

Code Quality

• ✅ Minimal changes (5 lines total across 2 files)
• ✅ Test coverage uses existing ScrollToYTwice test
• ✅ Follows existing code patterns in handlers
• ✅ No breaking API changes

---