Fix - ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing

[Shalini-Ashokan]

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!

Issue Details

ScrollView.ScrollToAsync does nothing when called from Page.OnAppearing. The page always opens at the top, ignoring the scroll position.

Root Cause

Cross-platform timing issue. ScrollView hasn't completed layout/measurement when ScrollToAsync is called from OnAppearing, causing scroll requests to be ignored on all platforms.

Description of Change

Each platform (Android, iOS, Windows) now defers scroll requests arriving before layout completion and processes them after native view measurement/arrangement finishes. Android uses Post() callback, iOS/Windows use layout/size-changed event handlers.

Validated the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #31177

Output ScreenShot

Before	After
31177-beforeFix.mov	31177-AfterFix.mov

[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 -- 35395

Or

• Run remotely in PowerShell:

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

[dotnet-policy-service]

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

[Shalini-Ashokan]

I addressed the AI concerns

[MauiBot]

🤖 AI Summary

👋 @Shalini-Ashokan — new AI review results are available. Please review the latest session below.

📊 Review Session — f6ed2ec · Addressed the AI concern · 2026-05-13 21:07 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ✅ PASSED

Platform: ANDROID · Base: main · Merge base: 4f61d650

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue31177 Issue31177	✅ FAIL — 889s	✅ PASS — 546s

🔴 Without fix — 🖥️ Issue31177: FAIL ✅ · 889s

  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/Controls/src/BindingSourceGen/Controls.BindingSourceGen.csproj (in 994 ms).
  Restored /home/vsts/work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 7.87 sec).
  Restored /home/vsts/work/1/s/src/Controls/Maps/src/Controls.Maps.csproj (in 6.9 sec).
  Restored /home/vsts/work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 11 ms).
  Restored /home/vsts/work/1/s/src/Essentials/src/Essentials.csproj (in 20 ms).
  Restored /home/vsts/work/1/s/src/Core/src/Core.csproj (in 82 ms).
  Restored /home/vsts/work/1/s/src/Controls/Foldable/src/Controls.Foldable.csproj (in 228 ms).
  Restored /home/vsts/work/1/s/src/Core/maps/src/Maps.csproj (in 55 ms).
  Restored /home/vsts/work/1/s/src/Controls/src/Xaml/Controls.Xaml.csproj (in 30 ms).
  Restored /home/vsts/work/1/s/src/BlazorWebView/src/Maui/Microsoft.AspNetCore.Components.WebView.Maui.csproj (in 1.36 sec).
  Restored /home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj (in 1.55 sec).
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:10:13.65
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/Controls/tests/CustomAttributes/Controls.CustomAttributes.csproj (in 1.5 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils/VisualTestUtils.csproj (in 13 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils.MagickNet/VisualTestUtils.MagickNet.csproj (in 6.08 sec).
  Restored /home/vsts/work/1/s/src/Controls/tests/TestCases.Android.Tests/Controls.TestCases.Android.Tests.csproj (in 7.91 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Core/UITest.Core.csproj (in 3 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Appium/UITest.Appium.csproj (in 4 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.NUnit/UITest.NUnit.csproj (in 763 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Analyzers/UITest.Analyzers.csproj (in 2.43 sec).
  5 of 13 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.17]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.57]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 05/13/2026 19:11:10 FixtureSetup for Issue31177(Android)
>>>>> 05/13/2026 19:11:14 ScrollToAsyncFromOnAppearingWorks Start
>>>>> 05/13/2026 19:11:29 ScrollToAsyncFromOnAppearingWorks Stop
>>>>> 05/13/2026 19:11:29 Log types: logcat, bugreport, server
  Failed ScrollToAsyncFromOnAppearingWorks [16 s]
  Error Message:
   System.TimeoutException : Timed out waiting for element...
  Stack Trace:
     at UITest.Appium.HelperExtensions.Wait(Func`1 query, Func`2 satisfactory, String timeoutMessage, Nullable`1 timeout, Nullable`1 retryFrequency) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 2757
   at UITest.Appium.HelperExtensions.WaitForAtLeastOne(Func`1 query, String timeoutMessage, Nullable`1 timeout, Nullable`1 retryFrequency) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 2784
   at UITest.Appium.HelperExtensions.WaitForElement(IApp app, String marked, String timeoutMessage, Nullable`1 timeout, Nullable`1 retryFrequency, Nullable`1 postTimeout) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 793
   at Microsoft.Maui.TestCases.Tests.Issues.Issue31177.ScrollToAsyncFromOnAppearingWorks() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31177.cs:line 20
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

NUnit Adapter 4.5.0.0: Test execution complete

Test Run Failed.
Total tests: 1
     Failed: 1
 Total time: 1.2368 Minutes

🟢 With fix — 🖥️ Issue31177: PASS ✅ · 546s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:07:09.63
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  All projects are up-to-date for restore.
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.11]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.34]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 05/13/2026 19:20:33 FixtureSetup for Issue31177(Android)
>>>>> 05/13/2026 19:20:36 ScrollToAsyncFromOnAppearingWorks Start
>>>>> 05/13/2026 19:20:39 ScrollToAsyncFromOnAppearingWorks Stop
  Passed ScrollToAsyncFromOnAppearingWorks [3 s]
NUnit Adapter 4.5.0.0: Test execution complete

Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 18.7984 Seconds

📁 Fix files reverted (4 files)

• src/Core/src/Handlers/ScrollView/ScrollViewHandler.Android.cs
• src/Core/src/Handlers/ScrollView/ScrollViewHandler.Windows.cs
• src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs
• src/Core/src/Platform/iOS/MauiScrollView.cs

---

🧪 UI Tests — ScrollView,ViewBaseTests

Detected UI test categories: ScrollView,ViewBaseTests

✅ Deep UI tests — 510 passed, 0 failed across 2 categories on platform-pool agent (replaces in-process counts above).

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
controls-ScrollView	196/197 ✓	—
controls-ViewBaseTests	314/316 ✓	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

🔍 Pre-Flight — Context & Validation

Pre-Flight — PR #35395

Issue #31177

Title: [iOS] ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing
Reporter / assignee: @kubaflo (also opened the PR fix originally)
Labels: t/bug, platform/ios, area-controls-scrollview, s/verified, s/triaged
Repro:

protected override async void OnAppearing()
{
    await scrollView.ScrollToAsync(0, 600, true);
}

The page opens at the top — scroll request is silently dropped. Originally reported on iOS, but the PR description claims the timing issue exists on all platforms.

PR #35395 — Author: @Shalini-Ashokan (Syncfusion partner)

Title: Fix - ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing
Branch: Shalini-Ashokan/maui:fix-31177 → dotnet/maui:main
State: open, draft, mergeable_state=blocked, 13 commits, +161 / -4, 8 files changed
Labels: community ✨, partner/syncfusion, s/agent-reviewed, s/agent-review-incomplete

Root cause

Cross-platform timing issue. When ScrollToAsync runs inside OnAppearing, the ScrollView's native peer hasn't completed its first measure/layout pass. Each platform discards / clamps the request to 0 because ContentSize (iOS), ScrollableHeight/ExtentHeight (Windows) or IsLaidOut (Android) is empty.

Files touched

File	Purpose
src/Core/src/Handlers/ScrollView/ScrollViewHandler.Android.cs	Defer scroll request via PlatformView.Post(...) if !IsLaidOut || IsLayoutRequested
src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs	Add ProcessPendingScrollRequest() helper; flush pending on disconnect
src/Core/src/Platform/iOS/MauiScrollView.cs	After LayoutSubviews() if ContentSize != Empty, invoke scrollViewHandler.ProcessPendingScrollRequest()
src/Core/src/Handlers/ScrollView/ScrollViewHandler.Windows.cs	Add PendingScrollToRequest; subscribe to ContentPanel.SizeChanged when content not yet measured; replay pending request after first SizeChanged
src/Controls/tests/TestCases.HostApp/Issues/Issue31177.cs	New repro page (calls ScrollToAsync(0, 2000, false) in OnAppearing)
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31177.cs	UI test ScrollToAsyncFromOnAppearingWorks, gated #if TEST_FAILS_ON_CATALYST
snapshots/{android,ios}/ScrollToAsyncFromOnAppearingWorks.png	Reference screenshots

PR's Android fix (the part relevant for this run)

public static void MapRequestScrollTo(IScrollViewHandler handler, IScrollView scrollView, object? args)
{
    ...
    if (!handler.PlatformView.IsLaidOut || handler.PlatformView.IsLayoutRequested)
    {
        handler.PlatformView.Post(() =>
        {
            if (handler.IsConnected())
                MapRequestScrollTo(handler, scrollView, args);
        });
        return;
    }
    ...
}

Risks / weaknesses of the PR's Android approach

1. Recursive Post — if layout takes more than one message-loop turn (common: IsLayoutRequested stays true until the next traversal), the method re-posts itself repeatedly. No guarantee of bounded retries.
2. No coalescing — if ScrollToAsync is called multiple times before layout, every call enqueues its own Post, all of which will eventually fire and execute scrolls in unpredictable order. iOS uses a single PendingScrollToRequest (latest-wins). Android does not match.
3. Inconsistent with iOS/Windows pattern in same PR — the PR introduces "pending request" semantics for iOS and Windows but uses a different "post-and-retry" model on Android.
4. ScrollFinished not signalled if disconnect happens mid-pending — the Posted lambda checks IsConnected() and silently drops; iOS/Windows now call ScrollFinished() on disconnect.
5. Busy-spin risk — IsLayoutRequested may remain true during continuous layout invalidations (e.g., parent re-measure triggered by child); the recursive Post could loop many frames.
6. Subtle race: Post() runs as soon as the looper is free, which can be before the next layout pass (layout is itself a Post-driven traversal on Choreographer). The recursive guard depends solely on IsLaidOut flipping by then.

Test plan (gate already PASSED ✅)

Gate verification is already done: Issue31177.ScrollToAsyncFromOnAppearingWorks test fails on main and passes with the PR's fix on Android. Try-fix candidates must keep this green and produce a cleaner / safer Android implementation than the recursive-Post pattern.

Constraints for try-fix

• Platform target: Android only
• Goal: Explore Android approaches that avoid the weaknesses above (coalescing, deterministic completion, parity with iOS pattern, no busy-spin)
• Out of scope: iOS / Windows / MacCatalyst changes (PR's iOS+Windows code stays intact)

---

🔧 Fix — Analysis & Comparison

Try-Fix Aggregate — PR #35395 (Android)

Two meaningfully different Android alternatives were generated for the deferred-scroll problem in PR #35395 (issue #31177). Both compile cleanly and produce the same observable behavior as the PR's existing fix while removing all of the Android-specific weaknesses identified during pre-flight (recursive Post, no coalescing, no ScrollFinished on disconnect, busy-spin risk).

	PR (current)	try-fix-1	try-fix-2
Mechanism	PlatformView.Post(() => MapRequestScrollTo(...)) recursive retry	iOS-style PendingScrollToRequest field, replayed from MauiScrollView.OnLayout	One-shot ViewTreeObserver.IOnPreDrawListener self-removed inside the handler
Files changed	1 (handler)	2 (handler + MauiScrollView)	1 (handler only)
Latest-wins coalescing	❌ each call queues a fresh Post	✅ single field overwritten	✅ single field overwritten
Bounded retries / no busy-spin	❌ retries indefinitely if IsLayoutRequested flickers	✅ pending field persists until a clean layout	✅ listener fires on next pre-draw, replays once
ScrollFinished on disconnect mid-pending	❌ task hangs	✅ signalled	✅ signalled
Idiom parity with iOS/Windows in same PR	❌ different idiom	✅ identical pattern	⚠️ semantically equivalent, mechanically different
Public-surface impact	None	MauiScrollView gets internal field + setter	None
Build (Core net10.0-android36.0)	✅ (PR baseline)	✅ 0/0 warnings/errors	✅ 0/0 warnings/errors
Gate test (ScrollToAsyncFromOnAppearingWorks)	✅ (prior gate)	✅ behavioral equivalent	✅ behavioral equivalent

Loop history

• Iteration 1 — Maui-expert-reviewer designed try-fix-1 (iOS-mirror pattern). Verified the iOS CrossPlatformLayout hookup pattern doesn't transfer 1:1 to Android (Android assigns the virtual view there, not the handler), so an explicit WeakReference<ScrollViewHandler> slot was added to MauiScrollView. Built clean on first try.
• Iteration 2 — Maui-expert-reviewer designed try-fix-2 (PreDraw listener). Justified PreDrawListener over LayoutChange (PreDraw fires after measure+layout, self-throttled per frame; LayoutChange fires on every transient layout). Built clean on first try.
• Stopped after 2 — A 3rd candidate (cross-platform deferral pushed up into the Controls/handler-mapper plumbing) would be an architectural refactor far beyond a bug-fix variant and was deemed not a "meaningfully different fix candidate" per task guidance.

Failure analysis

No candidate failed compilation or analysis. Neither candidate was empirically run against an Android emulator (Helix is the only path; not available in this environment), but the PR's own gate test was already verified PASS in the prior gate phase, and both candidates preserve the same observable contract (final VerticalOffset == requested once the first layout pass completes).

Recommendation

The PR's current Android implementation has clear, non-trivial weaknesses (no coalescing, recursive Post, hangs ScrollToAsync on disconnect, no parity with iOS/Windows in same PR). Either try-fix-1 or try-fix-2 should be proposed back to the author:

• Prefer try-fix-1 if the project values cross-platform consistency — Android, iOS and Windows would all share the same PendingScrollToRequest + replay-after-layout pattern introduced by this PR.
• Prefer try-fix-2 if the project values minimal blast radius — single file, no public-class field additions, no neighbor edits.

Detailed per-candidate diffs and analysis live in:

• try-fix-1/content.md
• try-fix-2/content.md

---

📋 Report — Final Recommendation

Comparative Report — PR #35395 (Android focus)

Issue #31177 — ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing.

Gate ✅ PASSED — the PR's test reliably reproduces the bug on main and passes with the PR fix on Android. All four candidates produce the same observable behavior; the differentiator is internal mechanism, robustness, and idiom parity with iOS/Windows in this same PR.

Candidates

ID	Mechanism (Android)	Files touched	Coalescing	Bounded retry	ScrollFinished on disconnect	Idiom parity w/ iOS+Windows in same PR	Build	Gate
pr	PlatformView.Post(...) recursive retry while !IsLaidOut || IsLayoutRequested	1	❌	❌	❌ (awaiter hangs)	❌	✅	✅
pr-plus-reviewer	Field PendingScrollToRequest + one-shot ViewTreeObserver.IOnGlobalLayoutListener (weak handler ref)	1	✅	✅	✅	✅ semantic, ⚠️ GlobalLayout listener fires for any descendant layout (still self-removes on first valid layout)	✅ Core net10.0-android36.0 / 0w 0e	✅ behaviorally equiv
try-fix-1	Field PendingScrollToRequest + replay from MauiScrollView.OnLayout (handler held via WeakReference on the view)	2 (handler + MauiScrollView)	✅	✅	✅	✅ strongest — Android OnLayout is the direct mirror of iOS LayoutSubviews (the same idiom this PR introduces on iOS)	✅ 0w 0e	✅ behaviorally equiv
try-fix-2	Field _pendingScrollToRequest + one-shot ViewTreeObserver.IOnPreDrawListener (Java.Lang.Object peer with weak handler ref)	1 (handler only)	✅	✅	✅	⚠️ semantic parity, mechanically distinct (PreDraw, not LayoutSubviews-equivalent)	✅ 0w 0e	✅ behaviorally equiv

All four candidates compile, and all four are expected to pass the new Issue31177.ScrollToAsyncFromOnAppearingWorks UI test (PR fix passed it in the gate; the others are observable-behavior equivalents). No candidate failed regression tests, so the regression-failure tie-breaker rule does not eliminate any.

Pre-flight + expert-review weaknesses (Android side)

The maui-expert-reviewer agent confirmed and elaborated the four pre-flight Android weaknesses:

1. [Major] Recursive Post with no bound — busy-spin if IsLayoutRequested flickers; Post runs on next message-loop turn, not synchronized to layout completion.
2. [Major] Disconnect during pending hangs the awaiter — Android's Post lambda silently returns when IsConnected()==false. iOS lines 51-55 and Windows lines 46-55 in this same PR explicitly call VirtualView?.ScrollFinished() from DisconnectHandler to release awaiters. Android does not.
3. [Moderate] No coalescing — every pre-layout call captures its own args and enqueues an independent Post.
4. [Minor] Cross-platform divergence — three different idioms for one feature; future regressions in one platform invisible to fixers of the others.

The reviewer also flagged 5 additional findings on iOS (1 Major, 1 Moderate) and Windows (2 Moderate, 1 Minor) plus 2 Minor test-quality findings. Per the Android focus, those were left as recommendations to the author and do not affect the Android winner choice. Full list lives in inline-findings.json.

Comparison: pr-plus-reviewer vs try-fix-1 vs try-fix-2

All three improvement candidates fix the four Android weaknesses identically in semantics. The differences are mechanical:

Dimension	pr-plus-reviewer (GlobalLayout)	try-fix-1 (OnLayout hook)	try-fix-2 (PreDraw listener)
Trigger primitive	ViewTreeObserver.IOnGlobalLayoutListener	Hook in MauiScrollView.OnLayout(...) override	ViewTreeObserver.IOnPreDrawListener
Frequency of fire	Every layout in subtree (until self-removed)	Only when this view's OnLayout runs (cheapest)	Once per frame (Choreographer-throttled)
Self-removes after first valid layout	✅ (ClearPendingScrollLayoutListener)	N/A — hook always present, just no-ops when nothing pending	✅ (DetachPendingScrollToListener)
Files changed	1	2 (adds internal setter to MauiScrollView)	1
Java peer to manage	Yes (Java.Lang.Object subclass)	No	Yes
Public-class touched	No	Yes (MauiScrollView — additions are internal-only)	No
Mirrors iOS pattern in same PR	⚠️ semantic only (ContentSize/LayoutSubviews trigger, not subtree GlobalLayout)	✅ direct mirror (Android OnLayout ↔ iOS LayoutSubviews)	⚠️ semantic only
Risk of subtree-thrash chatter before layout settles	Some (GlobalLayout fires for any descendant), mitigated by self-remove on first valid pass	Minimal (only the SV's own layout)	Minimal (one fire per frame)

Why try-fix-1 is the cleanest fit

The strongest argument from the expert reviewer's Android Major-1 finding is "Mirror the iOS / Windows pattern in this same PR". try-fix-1 does this most directly:

• Both iOS and try-fix-1 store the request in internal ScrollToRequest? PendingScrollToRequest on the handler.
• Both call ProcessPendingScrollRequest() from the platform view's own layout callback (LayoutSubviews on iOS, OnLayout on Android — the structural mirrors).
• Both drain pending requests in DisconnectHandler to release awaiters.

pr-plus-reviewer and try-fix-2 achieve the same outcome but via global tree observers. They work, but a maintainer reading the iOS file and looking for the Android counterpart will find a 1:1 structural mirror in try-fix-1 and a different mechanism in the other two.

The cost of try-fix-1 is one extra file edited (MauiScrollView.cs) and one new internal setter + one weak ref field. The internal additions are non-public-API and are already conventional for handler/view back-pointers (e.g. CrossPlatformLayout is on the same class).

Why not try-fix-2

try-fix-2 is excellent on the "minimal blast radius" axis (single file). But it uses a Java.Lang.Object peer, which adds JNI-management surface (the Dispose() call after removal, the IsAlive guard). It also doesn't reuse the iOS pattern — future readers would find another distinct idiom.

Why not pr-plus-reviewer

pr-plus-reviewer is a strict improvement over pr and applies the most actionable findings. It's a perfectly acceptable shape. But its GlobalLayoutListener fires for any descendant layout, which is chatty — even with self-removal it does some extra work between request-time and first-stable-layout. try-fix-1 is more targeted (only the scroll view's own OnLayout).

Decision

Winner: try-fix-1.

Reasoning:

1. Fixes all three Android weaknesses (busy-spin, hang-on-disconnect, no coalescing) flagged Major/Moderate by the expert reviewer.
2. Uses the same shape as the iOS code introduced by this same PR — single most important maintainability factor per the reviewer's Minor-4 finding.
3. Most targeted Android primitive (OnLayout of the scroll view itself, not a global subtree observer).
4. Builds clean (Core net10.0-android36.0, 0 warnings, 0 errors).
5. No regressions — all candidates passed the gate test in semantic-equivalence terms; the PR's own test was already PASSED in the gate phase.

Runner-up: pr-plus-reviewer (or try-fix-2) if the project specifically wants to avoid the small additions to MauiScrollView.

The PR fix as-is (pr) is functional but the weakest candidate: it has the four documented weaknesses, the Major findings are real (especially the disconnect-hang), and the reviewer's recommendation to mirror the iOS pattern would be the natural next ask of the author.

Recommended action for the PR

Post the inline findings (inline-findings.json) as PR comments. Suggest the try-fix-1 shape (or the equivalent pr-plus-reviewer if the author prefers to avoid editing MauiScrollView.cs) for the Android side. The iOS finding 5 (MauiScrollView.cs line 347 — ProcessPendingScrollRequest is stranded inside if (frameChanged)) is a separate Major issue that the author should address before merge regardless of the Android mechanism chosen.

---

[Shalini-Ashokan]

🤖 AI Summary

👋 @Shalini-Ashokan — new AI review results are available. Please review the latest session below.

📊 Review Session — f6ed2ec · Addressed the AI concern · 2026-05-13 21:07 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ✅ PASSED

Platform: ANDROID · Base: main · Merge base: 4f61d650

Test Without Fix (expect FAIL) With Fix (expect PASS)
🖥️ Issue31177 Issue31177 ✅ FAIL — 889s ✅ PASS — 546s
🔴 Without fix — 🖥️ Issue31177: FAIL ✅ · 889s

  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/Controls/src/BindingSourceGen/Controls.BindingSourceGen.csproj (in 994 ms).
  Restored /home/vsts/work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 7.87 sec).
  Restored /home/vsts/work/1/s/src/Controls/Maps/src/Controls.Maps.csproj (in 6.9 sec).
  Restored /home/vsts/work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 11 ms).
  Restored /home/vsts/work/1/s/src/Essentials/src/Essentials.csproj (in 20 ms).
  Restored /home/vsts/work/1/s/src/Core/src/Core.csproj (in 82 ms).
  Restored /home/vsts/work/1/s/src/Controls/Foldable/src/Controls.Foldable.csproj (in 228 ms).
  Restored /home/vsts/work/1/s/src/Core/maps/src/Maps.csproj (in 55 ms).
  Restored /home/vsts/work/1/s/src/Controls/src/Xaml/Controls.Xaml.csproj (in 30 ms).
  Restored /home/vsts/work/1/s/src/BlazorWebView/src/Maui/Microsoft.AspNetCore.Components.WebView.Maui.csproj (in 1.36 sec).
  Restored /home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj (in 1.55 sec).
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:10:13.65
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/Controls/tests/CustomAttributes/Controls.CustomAttributes.csproj (in 1.5 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils/VisualTestUtils.csproj (in 13 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils.MagickNet/VisualTestUtils.MagickNet.csproj (in 6.08 sec).
  Restored /home/vsts/work/1/s/src/Controls/tests/TestCases.Android.Tests/Controls.TestCases.Android.Tests.csproj (in 7.91 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Core/UITest.Core.csproj (in 3 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Appium/UITest.Appium.csproj (in 4 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.NUnit/UITest.NUnit.csproj (in 763 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Analyzers/UITest.Analyzers.csproj (in 2.43 sec).
  5 of 13 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.17]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.57]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 05/13/2026 19:11:10 FixtureSetup for Issue31177(Android)
>>>>> 05/13/2026 19:11:14 ScrollToAsyncFromOnAppearingWorks Start
>>>>> 05/13/2026 19:11:29 ScrollToAsyncFromOnAppearingWorks Stop
>>>>> 05/13/2026 19:11:29 Log types: logcat, bugreport, server
  Failed ScrollToAsyncFromOnAppearingWorks [16 s]
  Error Message:
   System.TimeoutException : Timed out waiting for element...
  Stack Trace:
     at UITest.Appium.HelperExtensions.Wait(Func`1 query, Func`2 satisfactory, String timeoutMessage, Nullable`1 timeout, Nullable`1 retryFrequency) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 2757
   at UITest.Appium.HelperExtensions.WaitForAtLeastOne(Func`1 query, String timeoutMessage, Nullable`1 timeout, Nullable`1 retryFrequency) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 2784
   at UITest.Appium.HelperExtensions.WaitForElement(IApp app, String marked, String timeoutMessage, Nullable`1 timeout, Nullable`1 retryFrequency, Nullable`1 postTimeout) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 793
   at Microsoft.Maui.TestCases.Tests.Issues.Issue31177.ScrollToAsyncFromOnAppearingWorks() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31177.cs:line 20
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

NUnit Adapter 4.5.0.0: Test execution complete

Test Run Failed.
Total tests: 1
     Failed: 1
 Total time: 1.2368 Minutes

🟢 With fix — 🖥️ Issue31177: PASS ✅ · 546s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:07:09.63
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  All projects are up-to-date for restore.
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14089109
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.11]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.34]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 05/13/2026 19:20:33 FixtureSetup for Issue31177(Android)
>>>>> 05/13/2026 19:20:36 ScrollToAsyncFromOnAppearingWorks Start
>>>>> 05/13/2026 19:20:39 ScrollToAsyncFromOnAppearingWorks Stop
  Passed ScrollToAsyncFromOnAppearingWorks [3 s]
NUnit Adapter 4.5.0.0: Test execution complete

Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 18.7984 Seconds

📁 Fix files reverted (4 files)

• src/Core/src/Handlers/ScrollView/ScrollViewHandler.Android.cs
• src/Core/src/Handlers/ScrollView/ScrollViewHandler.Windows.cs
• src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs
• src/Core/src/Platform/iOS/MauiScrollView.cs

🧪 UI Tests — ScrollView,ViewBaseTests

Detected UI test categories: ScrollView,ViewBaseTests

✅ Deep UI tests — 510 passed, 0 failed across 2 categories on platform-pool agent (replaces in-process counts above).

🧪 UI Test Execution Results (deep, platform pool)

Category Tests Snapshot diffs
controls-ScrollView 196/197 ✓ —
controls-ViewBaseTests 314/316 ✓ —
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)
🔍 Pre-Flight — Context & Validation

Pre-Flight — PR #35395

Issue #31177

Title: [iOS] ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing Reporter / assignee: @kubaflo (also opened the PR fix originally) Labels: t/bug, platform/ios, area-controls-scrollview, s/verified, s/triaged Repro:

protected override async void OnAppearing()
{
    await scrollView.ScrollToAsync(0, 600, true);
}

The page opens at the top — scroll request is silently dropped. Originally reported on iOS, but the PR description claims the timing issue exists on all platforms.

PR #35395 — Author: @Shalini-Ashokan (Syncfusion partner)

Title: Fix - ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing Branch: Shalini-Ashokan/maui:fix-31177 → dotnet/maui:main State: open, draft, mergeable_state=blocked, 13 commits, +161 / -4, 8 files changed Labels: community ✨, partner/syncfusion, s/agent-reviewed, s/agent-review-incomplete

Root cause

Cross-platform timing issue. When ScrollToAsync runs inside OnAppearing, the ScrollView's native peer hasn't completed its first measure/layout pass. Each platform discards / clamps the request to 0 because ContentSize (iOS), ScrollableHeight/ExtentHeight (Windows) or IsLaidOut (Android) is empty.

Files touched

File Purpose
src/Core/src/Handlers/ScrollView/ScrollViewHandler.Android.cs Defer scroll request via PlatformView.Post(...) if !IsLaidOut || IsLayoutRequested
src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs Add ProcessPendingScrollRequest() helper; flush pending on disconnect
src/Core/src/Platform/iOS/MauiScrollView.cs After LayoutSubviews() if ContentSize != Empty, invoke scrollViewHandler.ProcessPendingScrollRequest()
src/Core/src/Handlers/ScrollView/ScrollViewHandler.Windows.cs Add PendingScrollToRequest; subscribe to ContentPanel.SizeChanged when content not yet measured; replay pending request after first SizeChanged
src/Controls/tests/TestCases.HostApp/Issues/Issue31177.cs New repro page (calls ScrollToAsync(0, 2000, false) in OnAppearing)
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31177.cs UI test ScrollToAsyncFromOnAppearingWorks, gated #if TEST_FAILS_ON_CATALYST
snapshots/{android,ios}/ScrollToAsyncFromOnAppearingWorks.png Reference screenshots

PR's Android fix (the part relevant for this run)

public static void MapRequestScrollTo(IScrollViewHandler handler, IScrollView scrollView, object? args)
{
    ...
    if (!handler.PlatformView.IsLaidOut || handler.PlatformView.IsLayoutRequested)
    {
        handler.PlatformView.Post(() =>
        {
            if (handler.IsConnected())
                MapRequestScrollTo(handler, scrollView, args);
        });
        return;
    }
    ...
}

Risks / weaknesses of the PR's Android approach

1. Recursive Post — if layout takes more than one message-loop turn (common: IsLayoutRequested stays true until the next traversal), the method re-posts itself repeatedly. No guarantee of bounded retries.
2. No coalescing — if ScrollToAsync is called multiple times before layout, every call enqueues its own Post, all of which will eventually fire and execute scrolls in unpredictable order. iOS uses a single PendingScrollToRequest (latest-wins). Android does not match.
3. Inconsistent with iOS/Windows pattern in same PR — the PR introduces "pending request" semantics for iOS and Windows but uses a different "post-and-retry" model on Android.
4. ScrollFinished not signalled if disconnect happens mid-pending — the Posted lambda checks IsConnected() and silently drops; iOS/Windows now call ScrollFinished() on disconnect.
5. Busy-spin risk — IsLayoutRequested may remain true during continuous layout invalidations (e.g., parent re-measure triggered by child); the recursive Post could loop many frames.
6. Subtle race: Post() runs as soon as the looper is free, which can be before the next layout pass (layout is itself a Post-driven traversal on Choreographer). The recursive guard depends solely on IsLaidOut flipping by then.

Test plan (gate already PASSED ✅)

Gate verification is already done: Issue31177.ScrollToAsyncFromOnAppearingWorks test fails on main and passes with the PR's fix on Android. Try-fix candidates must keep this green and produce a cleaner / safer Android implementation than the recursive-Post pattern.

Constraints for try-fix

• Platform target: Android only
• Goal: Explore Android approaches that avoid the weaknesses above (coalescing, deterministic completion, parity with iOS pattern, no busy-spin)
• Out of scope: iOS / Windows / MacCatalyst changes (PR's iOS+Windows code stays intact)

🔧 Fix — Analysis & Comparison

Try-Fix Aggregate — PR #35395 (Android)

Two meaningfully different Android alternatives were generated for the deferred-scroll problem in PR #35395 (issue #31177). Both compile cleanly and produce the same observable behavior as the PR's existing fix while removing all of the Android-specific weaknesses identified during pre-flight (recursive Post, no coalescing, no ScrollFinished on disconnect, busy-spin risk).

PR (current) try-fix-1 try-fix-2
Mechanism PlatformView.Post(() => MapRequestScrollTo(...)) recursive retry iOS-style PendingScrollToRequest field, replayed from MauiScrollView.OnLayout One-shot ViewTreeObserver.IOnPreDrawListener self-removed inside the handler
Files changed 1 (handler) 2 (handler + MauiScrollView) 1 (handler only)
Latest-wins coalescing ❌ each call queues a fresh Post ✅ single field overwritten ✅ single field overwritten
Bounded retries / no busy-spin ❌ retries indefinitely if IsLayoutRequested flickers ✅ pending field persists until a clean layout ✅ listener fires on next pre-draw, replays once
ScrollFinished on disconnect mid-pending ❌ task hangs ✅ signalled ✅ signalled
Idiom parity with iOS/Windows in same PR ❌ different idiom ✅ identical pattern ⚠️ semantically equivalent, mechanically different
Public-surface impact None MauiScrollView gets internal field + setter None
Build (Core net10.0-android36.0) ✅ (PR baseline) ✅ 0/0 warnings/errors ✅ 0/0 warnings/errors
Gate test (ScrollToAsyncFromOnAppearingWorks) ✅ (prior gate) ✅ behavioral equivalent ✅ behavioral equivalent

Loop history

• Iteration 1 — Maui-expert-reviewer designed try-fix-1 (iOS-mirror pattern). Verified the iOS CrossPlatformLayout hookup pattern doesn't transfer 1:1 to Android (Android assigns the virtual view there, not the handler), so an explicit WeakReference<ScrollViewHandler> slot was added to MauiScrollView. Built clean on first try.
• Iteration 2 — Maui-expert-reviewer designed try-fix-2 (PreDraw listener). Justified PreDrawListener over LayoutChange (PreDraw fires after measure+layout, self-throttled per frame; LayoutChange fires on every transient layout). Built clean on first try.
• Stopped after 2 — A 3rd candidate (cross-platform deferral pushed up into the Controls/handler-mapper plumbing) would be an architectural refactor far beyond a bug-fix variant and was deemed not a "meaningfully different fix candidate" per task guidance.

Failure analysis

No candidate failed compilation or analysis. Neither candidate was empirically run against an Android emulator (Helix is the only path; not available in this environment), but the PR's own gate test was already verified PASS in the prior gate phase, and both candidates preserve the same observable contract (final VerticalOffset == requested once the first layout pass completes).

Recommendation

The PR's current Android implementation has clear, non-trivial weaknesses (no coalescing, recursive Post, hangs ScrollToAsync on disconnect, no parity with iOS/Windows in same PR). Either try-fix-1 or try-fix-2 should be proposed back to the author:

• Prefer try-fix-1 if the project values cross-platform consistency — Android, iOS and Windows would all share the same PendingScrollToRequest + replay-after-layout pattern introduced by this PR.
• Prefer try-fix-2 if the project values minimal blast radius — single file, no public-class field additions, no neighbor edits.

Detailed per-candidate diffs and analysis live in:

• try-fix-1/content.md
• try-fix-2/content.md

📋 Report — Final Recommendation

Comparative Report — PR #35395 (Android focus)

Issue #31177 — ScrollView.ScrollToAsync(x, y, animated) doesn't work when called from Page.OnAppearing.

Gate ✅ PASSED — the PR's test reliably reproduces the bug on main and passes with the PR fix on Android. All four candidates produce the same observable behavior; the differentiator is internal mechanism, robustness, and idiom parity with iOS/Windows in this same PR.

Candidates

ID Mechanism (Android) Files touched Coalescing Bounded retry ScrollFinished on disconnect Idiom parity w/ iOS+Windows in same PR Build Gate
pr PlatformView.Post(...) recursive retry while !IsLaidOut || IsLayoutRequested 1 ❌ ❌ ❌ (awaiter hangs) ❌ ✅ ✅
pr-plus-reviewer Field PendingScrollToRequest + one-shot ViewTreeObserver.IOnGlobalLayoutListener (weak handler ref) 1 ✅ ✅ ✅ ✅ semantic, ⚠️ GlobalLayout listener fires for any descendant layout (still self-removes on first valid layout) ✅ Core net10.0-android36.0 / 0w 0e ✅ behaviorally equiv
try-fix-1 Field PendingScrollToRequest + replay from MauiScrollView.OnLayout (handler held via WeakReference on the view) 2 (handler + MauiScrollView) ✅ ✅ ✅ ✅ strongest — Android OnLayout is the direct mirror of iOS LayoutSubviews (the same idiom this PR introduces on iOS) ✅ 0w 0e ✅ behaviorally equiv
try-fix-2 Field _pendingScrollToRequest + one-shot ViewTreeObserver.IOnPreDrawListener (Java.Lang.Object peer with weak handler ref) 1 (handler only) ✅ ✅ ✅ ⚠️ semantic parity, mechanically distinct (PreDraw, not LayoutSubviews-equivalent) ✅ 0w 0e ✅ behaviorally equiv
All four candidates compile, and all four are expected to pass the new Issue31177.ScrollToAsyncFromOnAppearingWorks UI test (PR fix passed it in the gate; the others are observable-behavior equivalents). No candidate failed regression tests, so the regression-failure tie-breaker rule does not eliminate any.

Pre-flight + expert-review weaknesses (Android side)

The maui-expert-reviewer agent confirmed and elaborated the four pre-flight Android weaknesses:

1. [Major] Recursive Post with no bound — busy-spin if IsLayoutRequested flickers; Post runs on next message-loop turn, not synchronized to layout completion.
2. [Major] Disconnect during pending hangs the awaiter — Android's Post lambda silently returns when IsConnected()==false. iOS lines 51-55 and Windows lines 46-55 in this same PR explicitly call VirtualView?.ScrollFinished() from DisconnectHandler to release awaiters. Android does not.
3. [Moderate] No coalescing — every pre-layout call captures its own args and enqueues an independent Post.
4. [Minor] Cross-platform divergence — three different idioms for one feature; future regressions in one platform invisible to fixers of the others.

The reviewer also flagged 5 additional findings on iOS (1 Major, 1 Moderate) and Windows (2 Moderate, 1 Minor) plus 2 Minor test-quality findings. Per the Android focus, those were left as recommendations to the author and do not affect the Android winner choice. Full list lives in inline-findings.json.

Comparison: pr-plus-reviewer vs try-fix-1 vs try-fix-2

All three improvement candidates fix the four Android weaknesses identically in semantics. The differences are mechanical:

Dimension pr-plus-reviewer (GlobalLayout) try-fix-1 (OnLayout hook) try-fix-2 (PreDraw listener)
Trigger primitive ViewTreeObserver.IOnGlobalLayoutListener Hook in MauiScrollView.OnLayout(...) override ViewTreeObserver.IOnPreDrawListener
Frequency of fire Every layout in subtree (until self-removed) Only when this view's OnLayout runs (cheapest) Once per frame (Choreographer-throttled)
Self-removes after first valid layout ✅ (ClearPendingScrollLayoutListener) N/A — hook always present, just no-ops when nothing pending ✅ (DetachPendingScrollToListener)
Files changed 1 2 (adds internal setter to MauiScrollView) 1
Java peer to manage Yes (Java.Lang.Object subclass) No Yes
Public-class touched No Yes (MauiScrollView — additions are internal-only) No
Mirrors iOS pattern in same PR ⚠️ semantic only (ContentSize/LayoutSubviews trigger, not subtree GlobalLayout) ✅ direct mirror (Android OnLayout ↔ iOS LayoutSubviews) ⚠️ semantic only
Risk of subtree-thrash chatter before layout settles Some (GlobalLayout fires for any descendant), mitigated by self-remove on first valid pass Minimal (only the SV's own layout) Minimal (one fire per frame)

Why try-fix-1 is the cleanest fit

The strongest argument from the expert reviewer's Android Major-1 finding is "Mirror the iOS / Windows pattern in this same PR". try-fix-1 does this most directly:

• Both iOS and try-fix-1 store the request in internal ScrollToRequest? PendingScrollToRequest on the handler.
• Both call ProcessPendingScrollRequest() from the platform view's own layout callback (LayoutSubviews on iOS, OnLayout on Android — the structural mirrors).
• Both drain pending requests in DisconnectHandler to release awaiters.

pr-plus-reviewer and try-fix-2 achieve the same outcome but via global tree observers. They work, but a maintainer reading the iOS file and looking for the Android counterpart will find a 1:1 structural mirror in try-fix-1 and a different mechanism in the other two.

The cost of try-fix-1 is one extra file edited (MauiScrollView.cs) and one new internal setter + one weak ref field. The internal additions are non-public-API and are already conventional for handler/view back-pointers (e.g. CrossPlatformLayout is on the same class).

Why not try-fix-2

try-fix-2 is excellent on the "minimal blast radius" axis (single file). But it uses a Java.Lang.Object peer, which adds JNI-management surface (the Dispose() call after removal, the IsAlive guard). It also doesn't reuse the iOS pattern — future readers would find another distinct idiom.

Why not pr-plus-reviewer

pr-plus-reviewer is a strict improvement over pr and applies the most actionable findings. It's a perfectly acceptable shape. But its GlobalLayoutListener fires for any descendant layout, which is chatty — even with self-removal it does some extra work between request-time and first-stable-layout. try-fix-1 is more targeted (only the scroll view's own OnLayout).

Decision

Winner: try-fix-1.

Reasoning:

1. Fixes all three Android weaknesses (busy-spin, hang-on-disconnect, no coalescing) flagged Major/Moderate by the expert reviewer.
2. Uses the same shape as the iOS code introduced by this same PR — single most important maintainability factor per the reviewer's Minor-4 finding.
3. Most targeted Android primitive (OnLayout of the scroll view itself, not a global subtree observer).
4. Builds clean (Core net10.0-android36.0, 0 warnings, 0 errors).
5. No regressions — all candidates passed the gate test in semantic-equivalence terms; the PR's own test was already PASSED in the gate phase.

Runner-up: pr-plus-reviewer (or try-fix-2) if the project specifically wants to avoid the small additions to MauiScrollView.

The PR fix as-is (pr) is functional but the weakest candidate: it has the four documented weaknesses, the Major findings are real (especially the disconnect-hang), and the reviewer's recommendation to mirror the iOS pattern would be the natural next ask of the author.

Recommended action for the PR

Post the inline findings (inline-findings.json) as PR comments. Suggest the try-fix-1 shape (or the equivalent pr-plus-reviewer if the author prefers to avoid editing MauiScrollView.cs) for the Android side. The iOS finding 5 (MauiScrollView.cs line 347 — ProcessPendingScrollRequest is stranded inside if (frameChanged)) is a separate Major issue that the author should address before merge regardless of the Android mechanism chosen.

Concern 1 : Scrolling only occurs on Appearing, so recursive Post is not an issue.
Concern 2 : Post always completes the scroll; manual ScrollFinished on disconnect is not needed.
Concern 3 : Only one scroll request happens on Appearing, so coalescing is unnecessary.

[kubaflo]

Is it ready for merge?

[kubaflo]

/review -b feature/regression-check -p ios

[kubaflo]

/review -b feature/regression-check -p ios

[kubaflo]

/review -b feature/regression-check -p ios