[Android] ScrollView: Fix HorizontalScrollBarVisibility not updating immediately at runtime

[SubhikshaSf4851]

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

The scrollbar visibility update was applied to MauiScrollView, which did not immediately trigger a layout refresh for the horizontal scrollbar. As a result, the scrollbar updated only after a slight scroll

Description of Change

Updated the call to PlatformInterop.RequestLayoutIfNeeded in MauiScrollView.cs to target the internal _hScrollView instead of the parent, ensuring the horizontal scrollbar visibility updates as expected.

Issues Fixed

Fixes #33400

Mac Platform
Related known scrollbar refresh behavior — refer #7767 (comment)

Tested the behavior in the following platforms

• Windows
• Android
• iOS
• Mac

Before Issue Fix	After Issue Fix
BeforeFix33400.mov	AftreFix33400.mov

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This pull request fixes a bug where horizontal scrollbar visibility changes on Android didn't update immediately. The fix changes the layout refresh target from the parent MauiScrollView to the internal _hScrollView component that actually manages the horizontal scrollbar.

Changes:

• Fixed horizontal scrollbar visibility update on Android by targeting the correct view for layout refresh
• Added UI test to verify scrollbar visibility updates immediately without requiring user scrolling
• Added test snapshots for Android verifying the fix

Reviewed changes

Copilot reviewed 3 out of 6 changed files in this pull request and generated 1 comment.

File	Description
src/Core/src/Platform/Android/MauiScrollView.cs	Changed RequestLayoutIfNeeded(this) to RequestLayoutIfNeeded(_hScrollView) to fix scrollbar refresh
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33400.cs	Added NUnit test to verify immediate scrollbar visibility updates
src/Controls/tests/TestCases.HostApp/Issues/Issue33400.cs	Added test page with buttons to toggle horizontal scrollbar visibility
src/Controls/tests/TestCases.Android.Tests/snapshots/android/*.png	Added screenshot verification snapshots for Never, Always, and Default visibility states

[sheiksyedm]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Splitted the Method · aa97729

---

Issue: #33400 - Runtime Scrollbar visibility not updating correctly on Android and macOS platforms
PR: #33528 - [Android] ScrollView: Fix HorizontalScrollBarVisibility not updating immediately at runtime
Author: SubhikshaSf4851 (community contributor, Syncfusion partner)
Platforms Affected: Android (primary fix), macOS (related known issue, tracked separately)
Current HEAD: aa9772998c9799ac5b4a99ae81667e4d56208362 ("Splitted the Method", Feb 23, 2026)

Issue Summary

On Android, when changing HorizontalScrollBarVisibility at runtime (Always ↔ Never, Always ↔ Default, etc.), the horizontal scrollbar does not update immediately. The change only takes effect after a scroll event. The issue is also reported on macOS (separate known issue).

Root Cause (from PR description)

PlatformInterop.RequestLayoutIfNeeded was called on MauiScrollView (the parent/outer view) instead of _hScrollView (the MauiHorizontalScrollView that actually owns the horizontal scrollbar). Triggering layout on the wrong view does not cause the horizontal scrollbar to refresh.

Files Changed

Fix files (1):

• src/Core/src/Platform/Android/MauiScrollView.cs (+1, -1)

Test files (6):

• src/Controls/tests/TestCases.HostApp/Issues/Issue33400.cs (+59, new)
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33400.cs (+43, new)
• src/Controls/tests/TestCases.Android.Tests/snapshots/android/Issue33400_Always.png (new)
• src/Controls/tests/TestCases.Android.Tests/snapshots/android/Issue33400_Default.png (new)
• src/Controls/tests/TestCases.Android.Tests/snapshots/android/Issue33400_Never.png (new)
• src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/Issue33400_Never.png (new)

Test type: UI Tests (screenshot-based)

PR Fix Approach

1-line change in MauiScrollView.SetHorizontalScrollBarVisibility():

• Before: PlatformInterop.RequestLayoutIfNeeded(this);
• After: PlatformInterop.RequestLayoutIfNeeded(_hScrollView);

Prior Agent Review Summary

A prior agent review was done on commit df44fbd (Feb 18, 2026). Key findings:

• Gate FAILED: Screenshot tests pass both with and without the fix (timing issue — bug only affects immediate update, but screenshot is taken after UI has already settled)
• Missing Windows snapshots: Only Issue33400_Never.png for Windows; Always and Default missing
• Default button scrolls: scrollView.ScrollToAsync(100, 0, true) in Default handler defeats test purpose

Changes Since Prior Review (latest commit aa9772998)

• Split single test method into 3 separate methods (Order 1, 2, 3) for Never/Always/Default
• This is the only change — core issues remain unresolved

Key Outstanding Issues

1. Windows snapshots: Issue33400_Always.png and Issue33400_Default.png are missing for Windows (only Never present)
2. Tests are still screenshot-based — fundamental problem with Gate detection unchanged
3. Default button still calls scrollView.ScrollToAsync(100, 0, true)

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33528	RequestLayoutIfNeeded(_hScrollView) instead of RequestLayoutIfNeeded(this)	⏳ PENDING (Gate)	MauiScrollView.cs (+1,-1)	1-line fix; correct target

---

🚦 Gate — Test Verification

---

📝 Review Session — Splitted the Method · aa97729

---

Result: ❌ FAILED (Environment Blocked + Prior Analysis)
Platform: android
Mode: Full Verification Attempted

Verification Details

The Gate verification task agent could not complete (build/test timed out). However, a prior Gate run on commit df44fbd already established:

• Tests WITHOUT fix: ✅ PASS (expected FAIL) ❌ — Gate FAILS
• Tests WITH fix: ✅ PASS ✅

Root Cause of Gate Failure (Unchanged from Prior Review)

The tests are screenshot-based and verify scrollbar visibility by screenshot comparison. The bug is about timing — without the fix, the scrollbar updates only after a scroll event (delayed layout refresh). With the fix, it updates immediately. However, a screenshot taken ~500ms after the tap shows the same final state in both cases because:

• With fix: Scrollbar updates immediately at tap
• Without fix: Scrollbar updates slightly later (but still before the screenshot is taken)

The screenshot assertion cannot distinguish between "updated immediately" and "updated with a brief delay." Both produce identical screenshots.

Changes Since Prior Gate (Latest Commit aa9772998)

The author's only change was splitting the single test method into 3 separate test methods (Order 1/2/3 for Never/Always/Default). This is a structural improvement but does NOT change the fundamental test approach. Screenshot-based verification still cannot detect the timing bug.

Additional Issues Confirmed

1. Missing Windows snapshots: Issue33400_Always.png and Issue33400_Default.png are missing for Windows; only Issue33400_Never.png exists. The test runs on #if ANDROID || WINDOWS so Windows CI will fail.

2. Default button triggers scroll: scrollView.ScrollToAsync(100, 0, true) in the Default button handler triggers a scroll which is exactly the workaround that masks the bug. Even without the fix, the Default screenshot would look correct (scrollbar visible due to scroll trigger).

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Splitted the Method · aa97729

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33528	RequestLayoutIfNeeded(_hScrollView) instead of RequestLayoutIfNeeded(this)	⏳ SKIPPED (Gate Failed)	MauiScrollView.cs (+1,-1)	Code fix is correct; tests insufficient

Exhausted: N/A — Fix phase skipped because Gate ❌ FAILED
Selected Fix: N/A — Gate did not pass; test improvements required before fix can be validated

Analysis

The PR's 1-line fix is technically correct:

• _hScrollView.HorizontalScrollBarEnabled and _hScrollView.ScrollbarFadingEnabled are set on _hScrollView
• Therefore PlatformInterop.RequestLayoutIfNeeded must target _hScrollView to trigger a layout refresh on the view that actually owns the horizontal scrollbar
• SetVerticalScrollBarVisibility correctly calls PlatformInterop.RequestLayoutIfNeeded(this) because the vertical scrollbar lives on the outer MauiScrollView

The fix is independently logical and matches the existing code pattern. However, the tests cannot validate that the fix actually works (Gate failed), so the PR cannot be merged as-is.

---

📋 Report — Final Recommendation

---

📝 Review Session — Splitted the Method · aa97729

---

⚠️ Final Recommendation: REQUEST CHANGES

Summary

PR #33528 fixes HorizontalScrollBarVisibility not updating immediately at runtime on Android. The 1-line code fix is technically correct and well-targeted. However, the tests do not catch the bug (Gate ❌ FAILED in prior review, environment blocked in this review), and additional test quality issues must be addressed before the PR can be merged.

This is a re-review of the PR at HEAD aa9772998 ("Splitted the Method", Feb 23, 2026). The author's latest change split the single test method into 3 separate ones (Never/Always/Default) but did not address the core test issues.

---

Root Cause

PlatformInterop.RequestLayoutIfNeeded was called on MauiScrollView (the outer container) instead of _hScrollView (the inner MauiHorizontalScrollView that owns the horizontal scrollbar). Requesting layout on the wrong view did not trigger a refresh of the horizontal scrollbar's visibility state, so the scrollbar only updated when a scroll event happened to trigger layout on the correct view.

Fix Quality

The fix itself is minimal, correct, and properly targeted:

• Before: PlatformInterop.RequestLayoutIfNeeded(this);
• After: PlatformInterop.RequestLayoutIfNeeded(_hScrollView);

This is consistent with the existing code pattern: SetVerticalScrollBarVisibility correctly uses PlatformInterop.RequestLayoutIfNeeded(this) because the vertical scrollbar lives on the outer MauiScrollView, while the horizontal scrollbar lives on the inner _hScrollView.

---

Issues Requiring Changes

1. 🔴 Tests Don't Catch the Bug (Gate ❌ FAILED)

Problem: The screenshot-based test passes both with and without the fix. The bug is about timing — without the fix, the scrollbar updates only after a scroll event, but by the time the screenshot is taken (~500ms after the tap), the UI has already rendered via normal refresh cycles. Both states produce identical screenshots.

The latest commit (splitting methods) does not address this — three separate screenshot methods have the same fundamental problem.

Required: The test needs a way to verify the scrollbar state immediately after visibility change, before any scroll events occur. Possible approaches:

• Use Appium element attribute inspection to check if the scrollbar element is visible/enabled directly after the tap, without relying on screenshot timing
• Or add a specific assertion that verifies the layout was immediately refreshed (e.g., checking HorizontalScrollBarEnabled state via platform reflection)
• Note: This is a hard problem — the author should clarify whether an alternative testing approach is feasible, or acknowledge this as a limitation and request a skip/waiver from the team

2. 🔴 Missing Windows Snapshot Baselines

Problem: The test uses #if ANDROID || WINDOWS, meaning it runs on Windows CI. But only Issue33400_Never.png exists for Windows — Issue33400_Always.png and Issue33400_Default.png are missing. Windows CI will fail on these tests.

Required: Either:

1. Add the missing Windows baseline snapshots (Issue33400_Always.png and Issue33400_Default.png in TestCases.WinUI.Tests/snapshots/windows/), OR
2. Change to #if ANDROID only if Windows testing is not necessary for this Android fix

3. 🟡 Default Button Triggers a Scroll (Masks Bug)

Problem: The Default button handler calls scrollView.ScrollToAsync(100, 0, true) after setting visibility. This triggers a scroll event, which is exactly the workaround that causes the scrollbar to update even without the fix. This:

• Makes the Default screenshot test unreliable as a regression test
• Obscures the bug (even without the fix, Default appears to work via the scroll trigger)

Recommendation: Remove scrollView.ScrollToAsync(100, 0, true) from the Default button handler.

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33528	RequestLayoutIfNeeded(_hScrollView)	❌ Gate Failed (tests don't catch bug)	MauiScrollView.cs (+1,-1)	Code fix is correct; test issues must be resolved

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [Android] ScrollView: Fix HorizontalScrollBarVisibility not updating immediately at runtime

Description: ✅ Good

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

In MauiScrollView.SetHorizontalScrollBarVisibility, PlatformInterop.RequestLayoutIfNeeded was called on this (the outer MauiScrollView), but the horizontal scrollbar lives on the inner _hScrollView (MauiHorizontalScrollView). Requesting layout on the outer view did not trigger a layout refresh for the inner horizontal scroll view, so the scrollbar visibility change (e.g., Always → Never) was not reflected visually until the user triggered a scroll.

Description of Change

Changed PlatformInterop.RequestLayoutIfNeeded(this) to PlatformInterop.RequestLayoutIfNeeded(_hScrollView) in MauiScrollView.SetHorizontalScrollBarVisibility.

This mirrors the pattern already used by SetVerticalScrollBarVisibility, where this is the correct target because the vertical scrollbar lives on the outer MauiScrollView. For horizontal scroll, the inner MauiHorizontalScrollView (_hScrollView) must be refreshed.

File changed:

• src/Core/src/Platform/Android/MauiScrollView.cs — One-line fix in SetHorizontalScrollBarVisibility

Tests added:

• src/Controls/tests/TestCases.HostApp/Issues/Issue33400.cs — HostApp page with a horizontal ScrollView and buttons to toggle HorizontalScrollBarVisibility between Always, Never, and Default
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33400.cs — UI tests (Android and Windows) verifying each visibility state via screenshot comparison

Known Related Issue (Out of Scope)

macOS has a similar scrollbar refresh problem (both horizontal and vertical). That is a separate, pre-existing issue tracked in #7767 and is not addressed by this PR.

Issues Fixed

Fixes #33400

Platforms Tested

• Android ✅ (fix applies here; UI tests + snapshot baselines added)
• Windows ✅ (UI test guard includes Windows; snapshot baseline added for Never)
• iOS — not applicable (fix is in Android platform code; iOS uses a different scrollbar implementation)
• Mac — not fixed (see Known Related Issue above)

Code Review: ✅ Passed

Code Review — PR #33528

PR: #33528 — [Android] ScrollView: Fix HorizontalScrollBarVisibility not updating immediately at runtime

---

🟡 Suggestions

1. Missing Windows Snapshot Baselines for Two Test Methods

File: src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/

Problem: The UI test class is compiled for #if ANDROID || WINDOWS, meaning all three test methods run on Windows:

• Issue33400ScrollbarVisibilityNever → calls VerifyScreenshot("Issue33400_Never")
• Issue33400ScrollbarVisibilityAlways → calls VerifyScreenshot("Issue33400_Always")
• Issue33400ScrollbarVisibilityDefault → calls VerifyScreenshot("Issue33400_Default")

However, only one Windows snapshot baseline is committed:

• ✅ src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/Issue33400_Never.png
• ❌ src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/Issue33400_Always.png (missing)
• ❌ src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/Issue33400_Default.png (missing)

This will cause the Issue33400ScrollbarVisibilityAlways and Issue33400ScrollbarVisibilityDefault Windows tests to fail on CI when baseline images don't exist.

Recommendation: Add the missing Windows snapshot baselines, or if horizontal scrollbar visibility is not meaningfully testable on Windows in this way, adjust the test guard (e.g., #if ANDROID) and remove the Windows snapshot.

---

2. Workaround Comment in HostApp Default Button Handler

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

Code:

defaultButton.Clicked += (s, e) =>
{
    scrollView.HorizontalScrollBarVisibility = ScrollBarVisibility.Default;
    scrollView.ScrollToAsync(100, 0, true);  //Slight scroll to show the scrollbar
};

Problem: The comment "Slight scroll to show the scrollbar" reads like the old workaround (the bug behavior — visibility only updates after a scroll). For ScrollBarVisibility.Default, Android may genuinely require a scroll to display the scrollbar (as it is shown on demand), so the ScrollToAsync call might be intentional. However, this is confusing given that the PR's purpose is to fix exactly this behavior.

Recommendation: Clarify the comment to distinguish between "workaround for the bug" vs "needed to reveal a Default-mode scrollbar that only appears during scroll activity". For example:

// ScrollBarVisibility.Default shows the scrollbar only while scrolling — trigger a scroll to make it visible for testing
scrollView.ScrollToAsync(100, 0, true);

---

✅ Looks Good

• Core fix is minimal and correct. The one-line change (PlatformInterop.RequestLayoutIfNeeded(_hScrollView) instead of this) is precisely targeted. It mirrors the symmetry already present in SetVerticalScrollBarVisibility (which correctly calls it on this because the vertical scrollbar lives on the outer view).

• Fix doesn't break vertical scrollbar. The SetVerticalScrollBarVisibility method continues to call RequestLayoutIfNeeded(this) unchanged — correct because the outer MauiScrollView owns the vertical scrollbar.

• Correct null guard preserved. The existing early-return for _hScrollView == null at line 114 still protects the new call, preventing a NullReferenceException if _hScrollView hasn't been initialized.

• Tests cover all three visibility states. Never, Always, and Default are all exercised via screenshot tests on Android with all three baselines committed.

• Test guard matches fix scope. Using #if ANDROID || WINDOWS (as updated from the prior TEST_FAILS_ON_CATALYST && TEST_FAILS_ON_IOS guard) is readable and intentional.

• HostApp page is well-structured. Clear layout with a horizontal ScrollView, three toggle buttons with descriptive AutomationIds, and realistic long text content to ensure the scrollbar appears.

---

[SubhikshaSf4851]

🤖 AI Summary

📊 Expand Full Review
📋 Expand PR Finalization Review

I’ve updated the changes based on the review. Specifically:

• Changed #if TEST_FAILS_ON_CATALYST && TEST_FAILS_ON_IOS to #if ANDROID || WINDOWS for better readability