[BagavathiPerumal]

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 Description

On iOS, a ScrollView configured with SafeAreaEdges="Container" incorrectly reserves the safe area twice, resulting in an additional phantom scroll range. When the content is smaller than the viewport, the ScrollView becomes unnecessarily scrollable. The extra scrollable area corresponds exactly to the combined safe-area insets (for example, 82 pt on an iPhone 11: 48 pt for the status bar and 34 pt for the home indicator).

When the content is taller than the viewport, the same issue causes an unnecessary dead over-scroll space at the end of the content.

Root Cause

The issue occurs because MauiScrollView.CrossPlatformArrange always pads the scroll content's measured size by the safe-area thickness when ContentInsetAdjustmentBehavior is not Automatic, without checking whether UIKit has already reserved the same space through AdjustedContentInset.

As a result, when SafeAreaEdges="Container" is set and the native inset is active, the safe area is accounted for twice—once by UIKit and once by the manual padding. This inflates the content size beyond its actual bounds and produces a phantom scrollable range, even when the content should not be scrollable.

Description of Change

The fix narrows the manual-padding condition so that it applies only when the native inset is genuinely inactive—that is, when SystemAdjustedContentInset is zero or ContentInsetAdjustmentBehavior is Never. In all other cases, UIKit's own inset is trusted to reserve the safe area, and the content size is left unchanged.

This removes the double reservation for SafeAreaEdges="Container" while preserving the existing None and Automaticbehaviors.

Tested the behavior in the following platforms.

• iOS
• Android
• Mac
• Windows

Issues Fixed

Fixes #36800

Output

Before Fix	After Fix
36800-BeforeFix.mov	36800-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 -- 37765

Or

• Run remotely in PowerShell:

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

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[vishnumenon2684]

/azp run maui-pr-uitests , maui-pr-devicetests

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).

[Copilot]

Pull request overview

This PR fixes iOS ScrollView phantom scrolling caused by duplicate safe-area reservation and adds regression coverage for issue #36800.

Changes:

• Avoids manual content-size padding when UIKit applies adjusted insets.
• Adds regression assertions and an iOS diagnostic host page.

Reviewed changes

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

File	Review summary
src/Core/src/Platform/iOS/MauiScrollView.cs	Critical (1 vote): Update the existing content-size test for the new no-double-reservation contract.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue36800.cs	Adds regression assertions for issue #36800.
src/Controls/tests/TestCases.HostApp/Issues/Issue36800.cs	Moderate (2 votes): Format the Phantom diagnostic using invariant culture to prevent locale-dependent parsing.

Suppressed comments (4)

src/Controls/tests/TestCases.HostApp/Issues/Issue36800.cs:62

• This diagnostic does not prove that the changed branch was exercised: it never checks that AdjustedContentInset is non-zero or that the native behavior is Always. If UIKit reports a zero system inset for this small-content fixture, both the old code and the new code take the SystemAdjustedContentInset == Zero path and the test can pass after reverting the fix. Include the native behavior/inset in the result and fail or otherwise mark the run when the active-inset setup was not reached, or use a fixture that guarantees that state.

			double phantom = (native.ContentSize.Height + native.AdjustedContentInset.Top + native.AdjustedContentInset.Bottom) - native.Bounds.Height;

src/Controls/tests/TestCases.HostApp/Issues/Issue36800.cs:7

• MauiScrollView is the UIKit implementation shared by iOS and MacCatalyst (the same file already contains a MacCatalyst-specific branch), but this new page is marked PlatformAffected.iOS and the companion test is guarded by #if IOS. Thus the changed safe-area path has no MacCatalyst regression coverage. Either include MacCatalyst in the page/test scope and UIKit guards, or document why this shared behavior is intentionally excluded.

[Issue(IssueTracker.Github, 36800, "ScrollView with SafeAreaEdges=\"Container\" reserves the safe area twice, causing phantom scroll range", PlatformAffected.iOS)]

src/Controls/tests/TestCases.HostApp/Issues/Issue36800.cs:31

• The repro only uses content that fits in the viewport, so it checks the small-content phantom range but not the tall-content case described by the fix. The changed branch also determines the native size while content is scrollable; add a tall-content scenario that reaches the bottom and validates the maximum offset so dead over-scroll regressions are caught.

		// Small content that comfortably fits within the viewport - the ScrollView
		// should NOT be scrollable at all when the bug is fixed.

src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue36800.cs:1

• MauiScrollView.cs under Platform/iOS is shared by iOS and MacCatalyst (the class also contains an OperatingSystem.IsMacCatalyst() branch), so this changed content-size path affects both platforms. #if IOS prevents this regression test from compiling in the Mac test project, and the host page is tagged only PlatformAffected.iOS; please add MacCatalyst coverage or document a concrete technical reason this UIKit path cannot reproduce there.

#if IOS // Fix is specific to iOS's ContentInsetAdjustmentBehavior/AdjustedContentInset handling; not applicable on Android/Catalyst/Windows

[MauiBot]

Expert Review — 4 findings

See inline comments for details.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Regression Prevention — This new condition inverts the contract asserted by the existing device test ContentSizeExpandsToViewport (src/Controls/tests/DeviceTests/Elements/ScrollView/ScrollViewTests.iOS.cs:34), and that test is not updated in this PR.

That test builds a ScrollView with SafeAreaEdges.Container (→ ContentInsetAdjustmentBehavior.Always) and asserts:

SafeAreaInsets.InsetRect(rect(0,0,ContentSize)).Height == AdjustedContentInset.InsetRect(Bounds).Height

With Always and a zero ContentInset, AdjustedContentInset == SafeAreaInsets, so the assertion reduces to ContentSize.Height == Bounds.Height.

• Before this change, the else if was ContentInsetAdjustmentBehavior != Automatic, which is unconditionally true in the else arm, so Always fell through to the padding and produced ContentSize.Height = (Bounds.H - safeArea.V) + safeArea.V = Bounds.H → assertion holds.
• After this change, Always + non-zero SystemAdjustedContentInset skips the padding, so ContentSize.Height = Bounds.H - safeArea.V → the assertion becomes Bounds.H - 2*safeArea.V == Bounds.H, which fails for any non-zero vertical safe area.

Concrete scenario: the device-test run executes ContentSizeExpandsToViewport on a simulator/device where the scroll view's SafeAreaInsets are non-zero (notched iPhone, or iPad with a status-bar inset) — the test fails. It only stays green if the test host's scroll view happens to have zero safe area insets, in which case it is passing vacuously and never covered this behavior at all.

The two behaviors cannot both be correct. Please either update ContentSizeExpandsToViewport to encode the new intended contract (content size equals the viewport, i.e. ContentSize.Height == Bounds.Height - AdjustedContentInset.Vertical) with a comment explaining the change, or explain why the old assertion is still expected to hold. Encoding the new contract in that device test is also cheaper and far more deterministic than the added Appium UI test, which needs a real safe area on the run device to discriminate.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[minor] Complexity Reduction / Performance-Critical Path — The predicate SystemAdjustedContentInset == UIEdgeInsets.Zero || ContentInsetAdjustmentBehavior == UIScrollViewContentInsetAdjustmentBehavior.Never now appears three times in this type: ValidateSafeArea (line 390), CrossPlatformArrange (line 453), and again on line 500. These three sites must stay in lockstep — if they ever diverge, _safeArea is derived from one source while the arrange bounds and the content-size padding assume another, which is exactly the double-reserve class of bug this PR fixes. Consider extracting it to a single private property (e.g. bool UIKitReservesSafeAreaNatively) so the three sites cannot drift.

Secondary point on the same line: SystemAdjustedContentInset is a computed property that reads two ObjC properties (AdjustedContentInset and ContentInset) across the managed/native boundary on every access. CrossPlatformArrange is on the layout hot path and now evaluates it twice per pass (line 453 and line 500). Hoisting it into a local at the top of the method removes two bridge round-trips per arrange.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Regression Prevention / Logic and Correctness — The value is formatted with the device's current culture but parsed with CultureInfo.InvariantCulture in the UI test (src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue36800.cs:29). $"Phantom={phantom}" on a double uses CurrentCulture, so on a device configured for a comma-decimal locale (de-DE, fr-FR, etc.) this emits e.g. Phantom=0,5. Invariant double.Parse uses NumberStyles.Float | AllowThousands, so "0,5" is parsed as the thousands-grouped value 5, not 0.5 — the test then reports a phantom range of 5pt for content that is actually correct, or silently reports a wrong magnitude in the failure message.

Format with the invariant culture to match the parser, e.g. _diagLabel.Text = string.Format(CultureInfo.InvariantCulture, "Phantom={0}", phantom); (or phantom.ToString(CultureInfo.InvariantCulture)).

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Regression Prevention — This assertion cannot discriminate the bug from a device that simply has no safe area, so it can pass vacuously. phantom is ContentSize.Height + AdjustedContentInset.Top + AdjustedContentInset.Bottom - Bounds.Height, which is exactly the safe-area thickness when the bug is present and 0 when it is fixed. If the scroll view's vertical safe area insets are zero on the run device/orientation (iPad simulator variants, landscape configurations, or any future runner change), phantom is ~0 with or without the fix and the test goes green regardless — the regression it exists to catch would no longer be detected.

Have OnDumpClicked also emit the measured AdjustedContentInset.Top + AdjustedContentInset.Bottom and assert here that it is greater than zero before asserting phantom <= 1.0. That turns a silently-vacuous pass into an explicit precondition failure.

Related, on line 29: double.Parse is reached for the "Phantom=NoHandler" branch too (it satisfies Does.StartWith("Phantom=") on line 26), so a missing handler surfaces as an opaque FormatException instead of a diagnosable assertion. Assert the text is not "Phantom=NoHandler"/"Phantom=Unknown" before parsing.

[MauiBot]

AI Review Summary

@BagavathiPerumal — new AI review results are available based on commit e00da3a.

---

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ✅ PASSED

Platform: IOS · Base: main · Merge base: e34b3fb9

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue36800 Issue36800	✅ FAIL — 313s	✅ PASS — 118s

🔴 Without fix — 🖥️ Issue36800: FAIL ✅ · 313s

Error-relevant lines (filtered from the build log):

     at Microsoft.Maui.TestCases.Tests.Issues.Issue36800.ScrollViewWithContainerSafeAreaDoesNotDoubleReserveSafeArea() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue36800.cs:line 31

🟢 With fix — 🖥️ Issue36800: PASS ✅ · 118s

(no coded error found; showing last 1200 chars)

d the specified pattern.
[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.07]   Discovering: Controls.TestCases.iOS.Tests
[xUnit.net 00:00:00.23]   Discovered:  Controls.TestCases.iOS.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 8/25/2026 4:41:25 AM FixtureSetup for Issue36800(iOS)
>>>>> 8/25/2026 4:41:30 AM ScrollViewWithContainerSafeAreaDoesNotDoubleReserveSafeArea Start
>>>>> 8/25/2026 4:41:31 AM ScrollViewWithContainerSafeAreaDoesNotDoubleReserveSafeArea Stop
  Passed ScrollViewWithContainerSafeAreaDoesNotDoubleReserveSafeArea [586 ms]
NUnit Adapter 4.5.0.0: Test execution complete
Results File: /Users/cloudtest/vss/_work/1/s/CustomAgentLogsTmp/UITests/TestResults/Issue36800.trx
Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 22.1125 Seconds
>>> TRX_RESULT_FILE: /Users/cloudtest/vss/_work/1/s/CustomAgentLogsTmp/UITests/TestResults/Issue36800.trx

📁 Fix files reverted (1 files)

• src/Core/src/Platform/iOS/MauiScrollView.cs

---

📋 Pre-Flight — Context & Validation

Issue: #36800 - iOS: ScrollView with SafeAreaEdges="Container" reserves the safe area twice
PR: #37765 - [iOS] Fix for ScrollView SafeAreaEdges="Container" Double Safe-Area Reservation Causing Phantom Scroll Range
Platform: iOS
Base / review commit: e34b3fb92b92408f9c5e3818d81923d75a394164 / 69320c9b1f54ec3aad54d9667981345989e27b18
Files changed: 1 implementation, 2 UI-test files
Gate: PASSED - the primary test fails without the PR fix and passes with it. Do not rerun gate verification.

Problem and Current Fix

For SafeAreaEdges.Container, MauiScrollView maps to UIKit's ContentInsetAdjustmentBehavior.Always. UIKit then reserves the safe area through AdjustedContentInset, while CrossPlatformArrange also adds _safeArea thickness to native ContentSize. The resulting scroll range is inflated by the inset thickness.

The PR changes the manual ContentSize padding condition from every non-Automatic behavior to only SystemAdjustedContentInset == UIEdgeInsets.Zero or ContentInsetAdjustmentBehavior.Never. Its new iOS UI test measures:

ContentSize.Height + AdjustedContentInset.Top + AdjustedContentInset.Bottom - Bounds.Height

and requires the value to be at most 1 point.

Changed Files

• src/Core/src/Platform/iOS/MauiScrollView.cs - implementation; only production target for alternative fixes.
• src/Controls/tests/TestCases.HostApp/Issues/Issue36800.cs - new iOS repro page.
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue36800.cs - new iOS Appium regression.

Required Tests

Primary test:

pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform ios -TestFilter "Issue36800"

Mandatory existing regression identified by review:

pwsh .github/skills/run-device-tests/scripts/Run-DeviceTests.ps1 -Project Controls -Platform ios -IncludeClasses "Microsoft.Maui.DeviceTests.ScrollViewTests" -IncludeMethods "ContentSizeExpandsToViewport"

No other regression tests were supplied. Do not run a category or full suite.

Review Constraints and Edge Cases

• Existing PR logic is not an alternative candidate: do not merely repeat the SystemAdjustedContentInset == Zero || Never content-size condition.
• ScrollViewTests.ContentSizeExpandsToViewport currently expects SafeAreaInsets.InsetRect(ContentSize).Size to equal AdjustedContentInset.InsetRect(Bounds).Size. Review feedback predicts the PR's reduced native ContentSize violates that established contract. Record empirical results rather than changing the test.
• The new host diagnostic formats with current culture while its test parses invariant culture. This is a test-quality finding, not permission to edit the added test files during try-fix.
• Confirm the candidate actually exercises Always with a non-zero system inset; a zero-inset pass would not prove the bug fixed.
• Consider small and tall content, Never/Automatic, rotation/keyboard invalidation, and the shared MacCatalyst implementation, but test only the two commands above on iOS.
• Never gate a per-view callback on Window.SafeAreaInsets, and never compare raw UIKit insets with edge-filtered _safeArea.
• Existing uncommitted .github/eng changes are harness-owned. Do not alter, revert, clean, or include them in candidate diffs.
• Follow .github/instructions/safe-area-ios.instructions.md, .github/instructions/threading-async.instructions.md, and the inline expert self-review required by the try-fix skill.

Candidate Baseline

EstablishBrokenBaseline.ps1 must be the only mechanism used to establish and restore the broken implementation. Candidate edits are limited to the script's RevertedFiles allow-list. Added PR test files remain read-only. Every attempt must restore with:

pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore

Original PR Candidate

Source	Approach	Gate	Known concern
PR #37765	Stop padding native ContentSize when Always has a non-zero system-adjusted inset	PASS	Predicted to break ContentSizeExpandsToViewport; test diagnostic is locale-sensitive

---

🔬 Code Review — Deep Analysis

Expert Evaluation — PR #37765

Verdict: REQUEST CHANGES
Confidence: medium

Independent assessment

The production change correctly targets the double-reservation path: when
SafeAreaEdges.Container selects UIKit's Always behavior and
SystemAdjustedContentInset is non-zero, CrossPlatformArrange stops adding
the same safe-area thickness to ContentSize. The change is localized to the
iOS/MacCatalyst scroll-view implementation and adds an iOS UI regression test.
The trusted Gate passed: the new test fails without the submitted fix and
passes with it.

Blocking concern

The new condition conflicts with the established
ScrollViewTests.ContentSizeExpandsToViewport device-test contract. Under
Always with a non-zero safe area, the submitted fix leaves
ContentSize.Height at Bounds.Height - safeArea, while that test expects the
native content size to expand to the full viewport. The required existing
regression test must determine whether this is a real behavior regression or
an obsolete contract; it cannot be assumed safe from the new UI test alone.

Additional findings

1. The HostApp diagnostic formats double with the current culture, but the UI
   test parses with InvariantCulture, producing incorrect values or failures
   on comma-decimal locales.
2. The UI test can pass vacuously when the device has zero vertical adjusted
   inset, and its NoHandler sentinel reaches double.Parse rather than
   yielding a diagnostic assertion.
3. The native/manual safe-area ownership predicate now appears three times in
   MauiScrollView; centralizing it would prevent future drift and avoid
   repeated managed/native property reads in the layout hot path.

The raw file:line findings are persisted in inline-findings.json.

---

🛠️ Try-Fix — Analysis & Comparison

Try-Fix Aggregate — PR #37765 (iOS ScrollView SafeAreaEdges="Container" double safe-area reservation)

Issue: #36800 · Platform: iOS · Target file: src/Core/src/Platform/iOS/MauiScrollView.cs
Gate: PASSED before try-fix (primary test fails without the PR fix, passes with it). Not rerun.

Candidates final: 2 of 2 attempted. None produced a Pass. Final verdict: BLOCKED.

#	Source	Approach	Result	Artifacts
0	PR #37765 (baseline approach, not a try-fix candidate)	Keep Always; narrow the manual ContentSize padding condition to SystemAdjustedContentInset == UIEdgeInsets.Zero || ContentInsetAdjustmentBehavior == Never	Gate PASS; predicted to break ContentSizeExpandsToViewport	—
1	try-fix attempt-1	Single-Owner Safe Area — map uniform SafeAreaEdges.Container to ContentInsetAdjustmentBehavior.Never so MAUI alone reserves the safe area	Blocked (baseline could not be established; 0 files changed; 0 self-review findings)	CustomAgentLogsTmp/PRState/37765/PRAgent/try-fix/attempt-1/
2	try-fix attempt-2	Native Inset-Ledger Compensation — keep Always and content-size padding, but offset only UIKit's duplicate effective scroll-inset ledger through explicit ContentInset	Blocked (baseline could not be established; 0 files changed; 0 self-review findings)	CustomAgentLogsTmp/PRState/37765/PRAgent/try-fix/attempt-2/

---

Original PR approach (#37765)

CrossPlatformArrange in MauiScrollView.cs previously padded native ContentSize by
_safeArea thickness for every non-Automatic adjustment behavior. For SafeAreaEdges.Container,
UpdateContentInsetAdjustmentBehavior() selects UIScrollViewContentInsetAdjustmentBehavior.Always, so
UIKit also reserves the safe area through AdjustedContentInset. The reservation is therefore counted
twice and the scrollable range is inflated by the inset thickness even when the content fits.

The PR's diff (against base e34b3fb92b92408f9c5e3818d81923d75a394164):

-			else if (ContentInsetAdjustmentBehavior != UIScrollViewContentInsetAdjustmentBehavior.Automatic)
+			else if (SystemAdjustedContentInset == UIEdgeInsets.Zero || ContentInsetAdjustmentBehavior == UIScrollViewContentInsetAdjustmentBehavior.Never)
 			{
+				// UIKit is not currently reserving any space for the safe area on
+				// this scroll view ... (comment)
 				width += _safeArea.HorizontalThickness;
 				height += _safeArea.VerticalThickness;
 			}
+			// UIKit is already reserving the safe area natively ... (comment)

Known concerns carried into try-fix: it leaves two safe-area owners alive and reconciles them with a
conditional that depends on UIKit having already published a non-zero inset for the current layout pass
(fragile across first layout, rotation, keyboard); and it shrinks native ContentSize below the viewport,
which is the invariant ScrollViewTests.ContentSizeExpandsToViewport asserts. The Issue36800 host
diagnostic also formats with current culture while the test parses invariant culture (test-quality only).

Candidates must not restate this mechanism — a renamed or rearranged conditional content-size-padding
fix does not count as an alternative.

---

Candidate 1 — Single-Owner Safe Area (Container → Never) — BLOCKED

Full self-contained narrative: CustomAgentLogsTmp/PRState/37765/PRAgent/try-fix-1/content.md
Attempt artifacts: CustomAgentLogsTmp/PRState/37765/PRAgent/try-fix/attempt-1/
(baseline.log, approach.md, result.txt = Blocked, fix.diff (empty), test-output.log,
analysis.md, reviewer-findings.json = [], reviewer-findings.diff (empty))

Approach

Change UpdateContentInsetAdjustmentBehavior() so a uniform SafeAreaRegions.Container maps to
UIScrollViewContentInsetAdjustmentBehavior.Never instead of .Always, joining SafeAreaRegions.All and
the SoftInput regions that already do so. MAUI then owns the container safe area outright:
ValidateSafeArea() takes its GetInset() branch, CrossPlatformArrange() insets the arrange rect
(origin and size), and the existing manual padding restores ContentSize to the full Bounds size. With
AdjustedContentInset identically zero, the scrollable range for fitting content is zero. Container
semantics hold because GetInset() derives from UIView.SafeAreaInsets (bars/notch, no keyboard).

Prior approach avoided

PR #37765 (the only prior approach; no earlier try-fix attempts exist). Its hypothesis is that the manual
content-size padding is the wrong half of an otherwise correct dual-ownership model. The failure mechanism
it preserves is simultaneous dual ownership of the safe area (UIKit's AdjustedContentInset plus
MAUI's _safeArea), reconciled only by a layout-pass-ordering-sensitive runtime conditional, and it
leaves ContentSize smaller than the viewport.

Mechanism-level difference

The candidate never touches the padding decision; it removes one owner at the source. Because the behavior
is Never, UIKit publishes no AdjustedContentInset, so both inset terms in
ContentSize.Height + AdjustedContentInset.Top + AdjustedContentInset.Bottom - Bounds.Height are
identically zero and the safe area is expressed exactly once, in the arrange rect, via the code path that
already serves every other non-Automatic region. The PR nulls MAUI's reservation and keeps UIKit's; this
candidate nulls UIKit's and keeps MAUI's — and in doing so also preserves the ContentSize == Bounds
invariant the existing device test encodes.

Files changed

None — blocked before any edit. fix.diff is empty; git status --porcelain --untracked-files=no -- src/ is empty.

(empty diff)

Tests

#	Command	Result
1	pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform ios -TestFilter "Issue36800"	NOT RUN (blocked)
2	pwsh .github/skills/run-device-tests/scripts/Run-DeviceTests.ps1 -Project Controls -Platform ios -IncludeClasses "Microsoft.Maui.DeviceTests.ScrollViewTests" -IncludeMethods "ContentSizeExpandsToViewport"	NOT RUN (blocked)

Neither was executed: with no candidate implementation on disk, both would have exercised the unmodified
PR tree and produced evidence attributable to the PR's fix rather than to this candidate. A Pass may never
be manufactured that way.

Overall result

Blocked. Inline expert self-review: 0 findings (no diff to review — documented Step 6 no-diff path).

Failure analysis

EstablishBrokenBaseline.ps1 aborted at its fail-fast cleanliness gate (line 392):
Working directory is not clean. git status --porcelain --untracked-files=no reports 40 modified
tracked files, all under .github/scripts/, .github/skills/, and eng/scripts/ — harness-owned changes
this invocation forbids altering, reverting, cleaning, or committing. The script has no bypass switch
(-BaseBranch, -DryRun, -Restore only), and its printed remediation (git commit / git checkout -- .) is prohibited by both the invocation and try-fix Principle 6. .github/.baseline-state.json was never
created, so per Step 2 the correct action is Blocked with no tracked-file edits.

Step 9 ran exactly pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore, completing with
Restored False / No baseline state found — the accepted verified no-state outcome for a Step-2 block
with zero edits. src/ re-verified clean; all harness paths left untouched.

Predicted test-contract conflict (code reading, not empirical)

ContentSizeExpandsToViewport asserts SafeAreaInsets.InsetRect(ContentSize).Size == AdjustedContentInset.InsetRect(Bounds).Size; under Always (where AdjustedContentInset == SafeAreaInsets) this reduces to ContentSize.Height == Bounds.Height. Issue36800 requires
ContentSize.Height + AdjustedContentInset.Top + AdjustedContentInset.Bottom - Bounds.Height <= 1.
Together these imply SafeAreaInsets.Vertical <= 1, so both can hold at once only when the scroll view's
own SafeAreaInsets is (near) zero in the device-test host. The PR's approach shrinks ContentSize below
Bounds and violates the device test whenever that inset is non-zero; the Never candidate keeps
ContentSize == Bounds and zeroes AdjustedContentInset, satisfying Issue36800 while staying
compatible with the device test's invariant. Unverified — must be confirmed on device.

---

Guidance for the next candidate

1. The block is environmental, not attempt-specific. Every candidate will hit the same
   EstablishBrokenBaseline.ps1 cleanliness failure until the harness commits or stashes its own
   .github/eng edits. Expect Blocked at Step 2 unless that precondition changes, and do not clean
   the tree to work around it.
2. Mechanisms already claimed: (a) PR #37765 — conditional content-size padding under Always
   [excluded]; (b) candidate 1 — Container → Never, single-owner safe area. Choose a third distinct
   root-cause hypothesis.
3. Mechanisms shown to be dead ends by analysis: zeroing _safeArea/_appliesSafeAreaAdjustments
   while keeping Always (arrange bounds then equal full Bounds, content fills Bounds.Height, and the
   non-zero AdjustedContentInset reproduces the phantom range); and subtracting
   SystemAdjustedContentInset from the padding term (arithmetic rearrangement of the PR's mechanism, and
   therefore excluded).
4. Do not modify the added PR test files (Issue36800.cs host page and shared test) or
   ScrollViewTests.iOS.cs. Record empirical conflicts instead of manufacturing compatibility.

---

Candidate 2 — Native Inset-Ledger Compensation — BLOCKED

Full self-contained narrative: CustomAgentLogsTmp/PRState/37765/PRAgent/try-fix-2/content.md
Attempt artifacts: CustomAgentLogsTmp/PRState/37765/PRAgent/try-fix/attempt-2/
(baseline.log, approach.md, result.txt = Blocked, fix.diff (empty), test-output.log,
analysis.md, reviewer-findings.json = [], reviewer-findings.diff (empty))

Approach

Keep ContentInsetAdjustmentBehavior.Always, keep the baseline MAUI _safeArea arrange geometry and
manual ContentSize padding rule unchanged, but compensate the duplicate reservation in UIKit's
scroll-range ledger by applying an equal-and-opposite explicit ContentInset for the container-safe-area
component when UIKit publishes its system adjustment. The intended synchronization point was
AdjustedContentInsetDidChange/safe-area invalidation, using pixel-level equality to prevent callback
oscillation.

Prior approaches avoided

PR #37765 conditionally suppresses manual ContentSize padding when SystemAdjustedContentInset is
non-zero; this candidate does not reproduce or arithmetically rearrange that content-size condition.
Candidate 1 remaps Container from Always to Never so MAUI becomes the sole safe-area owner; this
candidate keeps Always, keeps UIKit's non-zero system adjustment, and does not use behavior remapping or
that single-owner mechanism.

Mechanism-level difference

The distinct root-cause hypothesis is that the duplicate quantity is recorded in two different native
ledgers: MAUI's arranged-content geometry and UIKit's effective scroll insets. Rather than changing the
content extent (the PR) or selecting one safe-area owner (candidate 1), the proposed mechanism preserves
both layout inputs and offsets only the duplicated term in UIKit's effective scroll-range accounting via
explicit ContentInset. SystemAdjustedContentInset would remain non-zero evidence that .Always is
active. This remains a proposal only: the baseline safety gate prevented implementation and empirical
validation.

Files changed

None. src/Core/src/Platform/iOS/MauiScrollView.cs was never edited. The exact candidate diff is:

(empty diff)

Tests

#	Exact command	Result
1	pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform ios -TestFilter "Issue36800"	NOT RUN — BLOCKED BEFORE IMPLEMENTATION
2	pwsh .github/skills/run-device-tests/scripts/Run-DeviceTests.ps1 -Project Controls -Platform ios -IncludeClasses "Microsoft.Maui.DeviceTests.ScrollViewTests" -IncludeMethods "ContentSizeExpandsToViewport"	NOT RUN — BLOCKED BEFORE IMPLEMENTATION

The required order was therefore not entered. Running either command without a candidate diff would have
tested the unmodified PR tree and could not establish a candidate-2 Pass. Active .Always/non-zero-inset
evidence was unavailable because no candidate build or test could run.

Overall result

Blocked. A Pass requires both commands to execute and pass; neither executed. Inline expert self-review:
0 findings (reviewer-findings.json is []; no candidate diff existed).

Concrete failure analysis

pwsh .github/scripts/EstablishBrokenBaseline.ps1 failed its mandatory dirty-worktree safety gate before
creating .github/.baseline-state.json. It reported 40 tracked modifications, all in harness-owned
.github and eng paths that this invocation expressly prohibited altering, reverting, cleaning, staging,
committing, or stashing. With no baseline state there was no RevertedFiles allow-list, so editing the target
would violate the try-fix baseline-file boundary and could not be safely restored. The mechanism is therefore
unimplemented and non-empirical; its recursion behavior, edge filtering, rotation/keyboard invalidation, and
iOS/MacCatalyst effects remain untested.

All required no-diff artifacts were captured and passed the artifact existence gate. Step 9 then ran exactly
pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore, which completed with the accepted no-state result
Restored False / No baseline state found. A post-restore check confirmed .github/.baseline-state.json
was absent and the target implementation file had no attempt-created diff.

---

FINAL STEP 5a verdict

BLOCKED — 0 Pass, 0 Fail, 2 Blocked across exactly two candidates. Both invocations stopped at the
mandatory baseline cleanliness gate before implementation, so neither supplied empirical test evidence.
Candidate 1 proposed behavior remapping/single ownership; candidate 2 proposed native inset-ledger
compensation while retaining .Always and the baseline content-size rule. STEP 5a stopped after two
invocations as strictly bounded; no third candidate was attempted.

---

🏁 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Winner: pr-plus-reviewer

pr-plus-reviewer is the strongest candidate because it preserves the submitted
fix that passed the trusted Gate, then addresses the expert review's concrete
test-quality and maintainability findings. Its strengthened Issue36800 test
passed on iOS while requiring a non-zero adjusted inset, so the result exercises
the actual Always double-reservation scenario rather than passing vacuously.
The submitted PR still needs these reviewer changes, so approval is not
recommended.

Comparative ranking

Rank	Candidate	Implementation	Validation	Assessment
1	pr-plus-reviewer	Submitted fix plus centralized ownership predicate and robust invariant/non-zero-inset diagnostics	Gate inherited PASS; strengthened Issue36800 PASS (1/1); ContentSizeExpandsToViewport BLOCKED by Xcode/workload mismatch	Winner. Best implemented and tested candidate, but the existing device-test contract remains unverified.
2	pr	Suppress manual ContentSize padding when UIKit already supplies a non-zero system inset	Trusted Gate PASS	Directionally correct, but retains locale-sensitive and potentially vacuous test diagnostics, duplicates the ownership predicate, and has an unresolved expert concern about ContentSizeExpandsToViewport.
3	try-fix-1	Proposed mapping SafeAreaEdges.Container to Never so MAUI alone owns the inset	BLOCKED before implementation; no diff; no tests	Plausible arithmetic, but unimplemented and incompatible with the review requirement to prove Always with a non-zero native inset.
4	try-fix-2	Proposed compensating UIKit's inset ledger with an opposite explicit ContentInset	BLOCKED before implementation; no diff; no tests	Unimplemented and carries additional callback, oscillation, edge-filtering, rotation, keyboard, and MacCatalyst risk.

No candidate produced a regression-test failure. Both try-fix candidates rank
below the implemented candidates because they were blocked before producing
code or empirical evidence. The required existing device regression also did
not fail: its build was blocked before execution because the installed .NET iOS
workload requires Xcode 26.0 while this host has Xcode 26.5. That uncertainty
must not be represented as a pass.

Expert findings disposition

Finding	Raw PR	pr-plus-reviewer
Existing ContentSizeExpandsToViewport contract may conflict with the fix	Unresolved	Still uncertain; required test was attempted once but blocked before execution
Current-culture formatting with invariant parsing	Present	Fixed
Zero-inset vacuous pass and opaque missing-handler parse failure	Present	Fixed
Triplicated ownership predicate and repeated native reads	Present	Fixed

The raw PR is therefore not the winning candidate. Apply
pr-plus-reviewer/reviewer.patch, then obtain one valid
ContentSizeExpandsToViewport result in a compatible iOS toolchain before
merge.

---

🔗 Regression Cross-Reference

🔍 Regression Cross-Reference

⚠ Overlaps with prior bug-fix PRs — same files modified, but no exact line revert detected.

File	Fix PR	Fixed issue(s)
src/Core/src/Platform/iOS/MauiScrollView.cs	#34617	#6972, #8422, #10107, #10509, #11113, #11677, #11808, #11812, #12131, #12324, #14566, #15057, #15280, #15559, #16522, #17127, #17323, #17550, #17664, #17864, #18367, #18481, #18669, #18679, #18843, #18933, #19074, #19219, #19331, #19642, #20383, #20392, #20596, #20682, #20855, #20922, #21037, #21240, #21646, #21700, #21791, #21828, #22060, #22565, #22887, #23030, #23832, #23903, #24241, #24252, #24511, #24603, #24866, #25010, #25081, #25093, #25728, #25920, #25921, #26158, #26633, #26864, #26975, #27143, #27250, #27302, #27427, #27646, #27846, #28078, #28101, #28147, #28421, #28722, #28824, #28901, #28961, #29191, #29192, #29415, #29428, #29484, #29547, #29645, #29704, #29729, #29764, #29812, #29930, #30004, #30066, #30097, #30181, #30273, #30290, #30605, #30782, #30888, #30979, #31109, #31121, #31140, #31145, #31387, #31551, #31966, #32017, #32243, #32266, #32316, #32406, #32416, #32578, #32791, #32807, #32983, #32989, #32995, #33119, #33131, #33258, #33291, #33293, #33304, #33375, #33415, #33417, #33420, #33424, #33493, #33547, #33577, #33601, #33604, #33614, #33635, #33648, #33650, #33672, #33706, #33769, #33772, #33904, #33909, #33947, #33954, #33964, #33969, #33972, #34021, #34073, #34114, #34119, #34122, #34165, #34210, #34211, #34246, #34257, #34336, #34343, #34419, #34464, #34480, #34591, #34635, #34636, #34661

---

📱 UI Tests — SafeAreaEdges,ViewBaseTests

Detected UI test categories: SafeAreaEdges,ViewBaseTests

✅ Deep UI tests — 222 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
SafeAreaEdges	110/110 ✓	—
ViewBaseTests	112/112 ✓	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

🧭 Next Steps — reviewer changes required

The reviewer-enhanced candidate identified changes that are not yet in the submitted PR.

Why: pr-plus-reviewer preserves the Gate-proven production fix while correcting the expert review's locale, vacuous-test, missing-handler, and predicate-drift concerns. Its strengthened Issue36800 test passed with a non-zero adjusted inset; the existing device regression remains uncertain because an Xcode/workload mismatch blocked it before execution.

Address the actionable findings in this review before merging.