[Android] Fix ScrollView scroll position changes unexpectedly when Orientation is set to Horizontal and FlowDirection is RTL at runtime

[devanathan-vaithiyanathan]

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

Horizontal ScrollViews with FlowDirection=RightToLeft incorrectly position content at the left edge instead of the right edge on Android, breaking RTL user experience.

Description of Change

Added orientation tracking and improved RTL handling in Android ScrollView to maintain correct scroll position during orientation or flow direction changes.

Issues Fixed

Fixes #30081

Tested the behavior in the following platforms.

• Android
• Windows
• iOS
• Mac

Before	After
Android Before.mov	Android After.mov

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Fix the build errors · 8aca2fa

---

Issue: #30081 - [Android] ScrollView scroll position changes unexpectedly when Orientation is set to Horizontal and FlowDirection is RTL at runtime
PR: #32531 - [Android] Fix ScrollView scroll position changes unexpectedly when Orientation is set to Horizontal and FlowDirection is RTL at runtime
Platforms Affected: Android only
Files Changed: 4 implementation files, 2 test files

Issue Summary

When a ScrollView has Orientation=Horizontal and FlowDirection=RightToLeft, changing the orientation at runtime ( Horizontal) causes the scroll position to unexpectedly jump/alternate on Android. The content should be positioned at the right edge for RTL, but instead appears at the left edge.Vertical

Fix Approach (PR #32531)

1. Added _prevLayoutDirection and _checkedForRtlScroll state tracking fields to MauiScrollView
2. Added UpdateFlowDirection(IView) method in MauiScrollView to handle layout direction changes for horizontal scroll views
3. Added MapFlowDirection static handler in ScrollViewHandler.Android.cs
4. Registered MapFlowDirection in ScrollViewHandler.cs under #if ANDROID
5. In OnLayout: when _checkedForRtlScroll is false and scroll is RTL, posts a ScrollTo to the right end
6. Resets _checkedForRtlScroll when orientation changes
7. Sets _checkedForRtlScroll = true in OnScrollChange listener

Key Observations

• Fix is Android- uses #if ANDROID guard in ScrollViewHandler.csonly
• ViewExtensions.cs change: Made GetLayoutDirection static helper used internally (minor refactor from instance to static call)
• RTL initial positioning uses Post() to defer the scroll after layout completes
• No PR review comments or inline reviewer feedback found

Discussion / Disagreements

No reviewer discussions found.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #32531	Track _checkedForRtlScroll flag + UpdateFlowDirection method + RTL scroll in OnLayout via ` PENDING (Gate)	4 impl files	Original PR	Post()`

---

🚦 Gate — Test Verification

---

📝 Review Session — Fix the build errors · 8aca2fa

---

** FAILEDResult:**
Platform: android
Mode: Full Verification

Test Behavior

• Tests FAIL without fix ( bug is present)expected
• Tests PASS with ( missing baseline snapshot)FAILED fix

Root Cause of Gate Failure

The test VerifyHorizontalScrollViewPositionAtRuntime uses VerifyScreenshot() which requires a pre-committed baseline .png snapshot file. No baseline snapshot was committed with this PR.

Error:

VisualTestUtils.VisualTestFailedException:
Baseline snapshot not yet created:
  artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/snapshots/android/VerifyHorizontalScrollViewPositionAtRuntime.png

This means the test cannot differentiate between the buggy state and the fixed it fails unconditionally due to missing snapshot infrastructure.state

Required Fix

The PR author must either:

1. Commit the baseline screenshot (VerifyHorizontalScrollViewPositionAtRuntime.png) so VerifyScreenshot() works, OR
2. Replace VerifyScreenshot() with a concrete, snapshot-independent assertion (e.g., checking the element's scroll position or bounding rect)

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Fix the build errors · 8aca2fa

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #32531	Track flag + + RTL scroll in	PASS (Gate - partially: fails without fix)	4 impl files	Original skipped try-fix due to Gate failure

Exhausted: No ( Gate failed, try-fix not executed)skipped
Selected Fix: PR's try-fix exploration was skipped because Gate did not fully pass (tests fail both with and without fix due to missing baseline snapshot)fix

---

📋 Report — Final Recommendation

---

📝 Review Session — Fix the build errors · 8aca2fa

---

Final Recommendation: REQUEST CHANGES##

Summary

PR #32531 adds RTL scroll position fix for Android ScrollView when Orientation=Horizontal and FlowDirection=RightToLeft. The fix approach is sound and the code quality is good, but the Gate verification failed because the test uses VerifyScreenshot() without a committed baseline snapshot, making the test unable to validate the fix.

Root Cause (of the original bug)

When MauiScrollView is used in horizontal mode with RTL layout direction on Android, changing orientation at runtime resets the LayoutDirection without repositioning the horizontal scroll offset to the right end. The fix tracks _checkedForRtlScroll and re-positions the horizontal scroll to the right edge via Post() in OnLayout.

Gate FAILEDResult:

• Tests FAIL without fix bug is detectable)correct (
• Tests FAIL with missing baseline snapshot)incorrect fix (
• VerifyHorizontalScrollViewPositionAtRuntime uses VerifyScreenshot() but no baseline .png was committed

Required Changes

1. Fix the missing baseline snapshottest

The test VerifyHorizontalScrollViewPositionAtRuntime calls VerifyScreenshot() but the baseline screenshot file was not committed. This means the test always fails regardless of the fix state.

Option A: Commit the baseline screenshot for all relevant platforms.

Option B (preferred): Replace VerifyScreenshot() with a concrete Appium-based assertion that does not require a pre-existing snapshot. For example, verify the scroll position of the horizontal scroll view element is at the right edge after toggling orientation:

[Test]
[Category(UITestCategories.ScrollView)]
public void VerifyHorizontalScrollViewPositionAtRuntime()
{
    App.WaitForElement("ToggleOrientationButton");
    App.Tap("ToggleOrientationButton");
    // Verify RTL content is scrolled to the right edge (x position near 0 for RTL)
    // Use element bounds to assert content is positioned correctly
    App.WaitForElement("ScrollViewContent");
    VerifyScreenshot(); // Only keep if baseline is committed
}

2. Code quality observations (non-blocking)

• The UpdateFlowDirection method and MapFlowDirection handler look correct
• GetLayoutDirection refactoring in ViewExtensions.cs is a minimal but valid change
• The _checkedForRtlScroll = true in OnScrollChange is a reasonable optimization to avoid redundant scroll calls
• Edge case: rapid orientation toggles may cause visible scroll flicker; consider adding a guard for in-flight post operations

Fix Quality (once test is fixed)

The core implementation is sound. The PR correctly:

1. Tracks layout direction changes to avoid redundant work
2. Resets RTL tracking when orientation changes
3. Uses Post() to defer RTL scroll positioning after layout completes
4. Registers MapFlowDirection mapper specifically for Android

Recommendation

Request the author to fix the test by committing baseline screenshots or replacing VerifyScreenshot() with concrete assertions. The fix code itself is correct.

---

📋 Expand PR Finalization Review

---

Title: ⚠️ Needs Update

Current: [Android] Fix ScrollView scroll position changes unexpectedly when Orientation is set to Horizontal and FlowDirection is RTL at runtime

Recommended: [Android] ScrollView: Fix RTL horizontal scroll position on orientation change

Description: ⚠️ Needs Update

Description needs updates. See details below.

✨ Suggested PR Description

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

On Android, MauiHorizontalScrollView (the inner view used for horizontal scrolling) does not receive FlowDirection updates — only the outer NestedScrollView (MauiScrollView) did. When Orientation changed at runtime, a new _hScrollView was created without the correct LayoutDirection, so the scroll position was not initialized to the right-hand edge for RTL. This caused the scroll position to alternate unexpectedly between left and right edges each time orientation toggled.

Description of Change

src/Core/src/Platform/Android/ViewExtensions.cs

• Changed GetLayoutDirection from private to internal so it can be called from MauiScrollView without duplicating logic.

src/Core/src/Handlers/ScrollView/ScrollViewHandler.cs + ScrollViewHandler.Android.cs

• Registered a new Android-only MapFlowDirection mapper that calls MauiScrollView.UpdateFlowDirection when IView.FlowDirection changes.

src/Core/src/Platform/Android/MauiScrollView.cs

• Added UpdateFlowDirection(IView view) which sets LayoutDirection on _hScrollView (horizontal) or this (vertical/both).
• Added _checkedForRtlScroll flag that resets when orientation changes or when FlowDirection changes, allowing RTL initial-position logic to re-run.
• In OnLayout, when RTL scroll is not yet positioned (_checkedForRtlScroll == false) and orientation is horizontal, Posts a scroll to the child's full width to position at the right edge.
• In IOnScrollChangeListener.OnScrollChange, sets _checkedForRtlScroll = true so that once the user manually scrolls, the automatic RTL positioning does not override it.

Issues Fixed

Fixes #30081

Platforms Tested

• Android
• iOS (not affected — Android-only fix)
• Windows (not affected — Android-only fix)
• Mac (not affected — Android-only fix)

Code Review: ✅ Passed

Code Review — PR #32531

🟡 Suggestions

---

1. MapFlowDirection should be public, not internal

File: src/Core/src/Handlers/ScrollView/ScrollViewHandler.Android.cs

Problem: All other Map* methods in ScrollViewHandler are public static. Making MapFlowDirection internal breaks the pattern and prevents external consumers from overriding or calling the mapper directly (e.g., custom handlers derived from ScrollViewHandler).

Recommendation:

// Change:
internal static void MapFlowDirection(IScrollViewHandler handler, IScrollView scrollView)

// To:
public static void MapFlowDirection(IScrollViewHandler handler, IScrollView scrollView)

---

2. UI test doesn't cover the alternating-position regression (core of the bug)

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30081.cs

Problem: The test taps once and takes a screenshot. The reported bug was that the position alternates on each toggle. A single tap only goes Vertical→Horizontal; it doesn't verify the position is stable across multiple toggles (the regression would need at least 2–3 toggles to manifest).

Recommendation: Consider tapping the toggle button multiple times and verifying the screenshot is consistent:

App.WaitForElement("ToggleOrientationButton");
App.Tap("ToggleOrientationButton"); // Vertical -> Horizontal
VerifyScreenshot("after_first_toggle");
App.Tap("ToggleOrientationButton"); // Horizontal -> Vertical
App.Tap("ToggleOrientationButton"); // Vertical -> Horizontal again
VerifyScreenshot("after_third_toggle"); // Should match first screenshot

Without this, the test may pass even if the alternating-position bug is not fixed.

---

3. ScrollOrientation.Both is not tested

File: src/Controls/tests/TestCases.HostApp/Issues/Issue30081.cs

Problem: The issue description explicitly states: "Note: This issue also arises when Orientation is set to Both." The MauiScrollView code for UpdateFlowDirection has a guard _scrollOrientation == ScrollOrientation.Horizontal so Both orientation is NOT handled by the same path. It falls through to the else branch which only sets this.LayoutDirection. It's unclear whether this fixes the Both case.

Recommendation: Add a test case or at least verify manually that ScrollOrientation.Both is also fixed.

---

4. Dead code in ScrollViewViewModel

File: src/Controls/tests/TestCases.HostApp/Issues/Issue30081.cs

Problem: The view model has ContentText property, _contentText backing field, and logic to create a new Label when ContentText changes. None of this is bound or used in the page — the content is set directly in the constructor and never changed through ContentText. This dead code adds noise and confusion.

Recommendation: Remove ContentText, _contentText, and the corresponding setter logic.

---

5. RTL initial scroll position may be inaccurate

File: src/Core/src/Platform/Android/MauiScrollView.cs

Problem: The RTL initial-scroll logic in OnLayout uses:

_hScrollView?.ScrollTo(_hScrollView?.GetChildAt(0)?.Width ?? 0, 0);

This scrolls to the child's intrinsic Width, which may not equal the actual maximum scroll offset if the child has margins or if the horizontal scroll view's width is > 0. The correct maximum scroll offset is typically child.Width - hScrollView.Width for LTR, but for RTL Android already handles direction natively once LayoutDirection is set — so forcibly scrolling to child.Width may overshoot or undershoot.

Recommendation: Verify this is correct or consider using _hScrollView.MaxScrollAmount or computing max scroll as Math.Max(0, childWidth - hScrollViewWidth) to get the true end position.

---

6. Mixed indentation in Issue30081.cs

File: src/Controls/tests/TestCases.HostApp/Issues/Issue30081.cs

Problem: The file mixes 4-space indentation (constructor body at outer scope) and tab indentation (ScrollView, Button object initializers). This is inconsistent with the rest of the MAUI codebase.

Recommendation: Normalize to consistent tab (or space) indentation.

---

7. Platforms tested in description are inaccurate

File: PR description

Problem: iOS, Windows, and Mac are checked as tested, but the change is wrapped in #if ANDROID — it has no effect on those platforms. Checking them implies they were regression-tested, which may mislead reviewers.

Recommendation: Uncheck iOS, Windows, and Mac in the tested platforms list, or add a note explaining they were tested to confirm no regression.

---

✅ Looks Good

• The _checkedForRtlScroll flag pattern is sound: reset on orientation change, reset on flow direction change, locked once user scrolls — prevents fighting with user interaction.
• Making GetLayoutDirection internal rather than duplicating the logic is the right approach.
• Handler registration via #if ANDROID in ScrollViewHandler.cs is the established pattern for Android-only mappers in this file.
• Post() lambda correctly defers scroll until after layout is complete, avoiding scroll-before-measure issues.

---

[Copilot]

Pull request overview

Fixes Android RTL behavior for horizontally scrolling ScrollView when orientation/flow direction changes at runtime, addressing the unexpected scroll position shifts reported in #30081.

Changes:

• Exposes Android GetLayoutDirection(IView) helper for reuse outside ViewExtensions.
• Adds Android-specific FlowDirection mapping and RTL scroll-position correction logic in MauiScrollView.
• Adds a UI test + HostApp issue page for Issue30081.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/Core/src/Platform/Android/ViewExtensions.cs	Makes GetLayoutDirection(IView) internal so other Android platform code can reuse it.
src/Core/src/Platform/Android/MauiScrollView.cs	Tracks layout direction and applies RTL-specific scroll positioning for horizontal scrolling scenarios.
src/Core/src/Handlers/ScrollView/ScrollViewHandler.cs	Adds Android-only mapper entry for IView.FlowDirection on ScrollViewHandler.
src/Core/src/Handlers/ScrollView/ScrollViewHandler.Android.cs	Implements MapFlowDirection to route FlowDirection updates to MauiScrollView.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30081.cs	Adds a UI test intended to catch the RTL/horizontal runtime scroll position regression.
src/Controls/tests/TestCases.HostApp/Issues/Issue30081.cs	Adds the HostApp reproduction page used by the UI test.

Comments suppressed due to low confidence (1)

src/Core/src/Platform/Android/MauiScrollView.cs:201

• Resetting _checkedForRtlScroll only when the orientation changes may not cover the other repro path mentioned in the issue: updating/replacing ScrollView content at runtime while staying in horizontal/RTL. In that case a new layout may occur but _checkedForRtlScroll remains true, so the RTL correction path won’t re-evaluate. Consider also resetting this flag when the horizontal scroller is (re)created / content is swapped into _hScrollView (e.g., when _hScrollView is first created or when _content is moved between parents).

		public void SetOrientation(ScrollOrientation orientation)
		{
			bool orientationChanged = _scrollOrientation != orientation;
			_scrollOrientation = orientation;

			// Reset RTL tracking when orientation changes
			if (orientationChanged)
			{
				_checkedForRtlScroll = false;
			}

			if (orientation == ScrollOrientation.Horizontal || orientation == ScrollOrientation.Both)
			{
				if (_hScrollView == null)
				{
					_hScrollView = new MauiHorizontalScrollView(Context, this)
					{
						FillViewport = true
					};

					_hScrollView.HorizontalFadingEdgeEnabled = HorizontalFadingEdgeEnabled;
					_hScrollView.SetFadingEdgeLength(HorizontalFadingEdgeLength);
					SetHorizontalScrollBarVisibility(_horizontalScrollVisibility);
				}

				_hScrollView.IsBidirectional = _isBidirectional = orientation == ScrollOrientation.Both;

				if (_hScrollView.Parent != this)
				{
					if (_content != null)
					{
						_content.RemoveFromParent();
						_hScrollView.AddView(_content);
					}

					AddView(_hScrollView);
				}
				// If the user has changed between horiztonal and both we want to request a new layout
				// so the Horizontal Layout can be adjusted to satisfy the new orientation.
				else if (orientationChanged)
				{
					PlatformInterop.RequestLayoutIfNeeded(this);
				}
			}

[kubaflo]

/review -b feature/refactor-copilot-yml

[kubaflo]

Could you please check the ai's suggestions?

[kubaflo]

/review -b feature/enhanced-reviewer -p android

[kubaflo]

Could you please check the ai's suggestions?