[Android] Fix SafeAreaShouldWorkOnAllShellTabs test failure on API 36

[praveenkumarkarunanithi]

Root Cause

During Shell tab navigation animations, views move from off-screen into their final positions (for example, viewLeft < 0 during horizontal movement or elevated viewTop values during vertical movement). The existing logic applied Math.Max(0, position - margin) to account for margins, which clamped negative or small positive values to zero. This erased the signal used to detect that a view was still animating, causing the safe area logic to treat animating views as already settled. As a result, safe area padding was reduced too early during the final animation frames, leading to visible padding jumps.

Description of Change

To preserve correct animation detection, the animation state is now calculated using raw view position values before any margin clamping is applied, ensuring off-screen and in-transition states are not lost. The safe area calculation logic was also reordered so animation checks are evaluated before overlap checks for the left and right edges. This prevents partial padding from being applied when a view is near its final position but still animating. Finally, the animation flags were renamed to viewIsAnimatingHorizontally and viewIsAnimatingVertically for clarity.

Note

The test case SafeAreaShouldWorkOnAllShellTabs already exists on the main branch (Issue33034.cs). It was validated locally on an API 36 emulator to confirm the regression. Before the fix, the test failed due to incorrect safe area padding during Shell tab animations. After applying the fix, the test passes, confirming that safe area padding is correctly maintained throughout the animation cycle.

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Output Video

Before Issue Fix	After Issue Fix
Beforefix_36.mov	AfterFix_36.mov

[Copilot]

Pull request overview

Fixes Android safe-area padding instability during Shell tab transition animations (notably impacting the SafeAreaShouldWorkOnAllShellTabs UI test on API 36) by preserving raw view position signals used to detect in-progress animations.

Changes:

• Computes horizontal/vertical “view is animating” state using raw on-screen coordinates before margin clamping occurs.
• Reorders left/right edge logic to evaluate animation state before overlap-based partial inset reduction.
• Renames animation flags for clarity (viewIsAnimatingHorizontally, viewIsAnimatingVertically).

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

Or

• Run remotely in PowerShell:

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

[MauiBot]

🚦 Gate - Test Before and After Fix

📊 Expand Full Gate — 39ebc45 · Merge branch 'main' into fix-33034-api36

---

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent:

@copilot write tests for this PR

The agent will analyze the issue, determine the appropriate test type (UI test, device test, unit test, or XAML test), and create tests that verify the fix.

---

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 39ebc45 · Merge branch 'main' into fix-33034-api36

---

🔍 Pre-Flight — Context & Validation

---

Issue: #33034 - SafeAreaEdges works correctly only on the first tab in Shell. Other tabs have content colliding with the display cutout in the landscape mode.
PR: #34239 - [Android] Fix SafeAreaShouldWorkOnAllShellTabs test failure on API 36
Platforms Affected: Android (landscape mode with display cutout/notch), specifically reproduced on API 36 emulator
Files Changed: 1 implementation (src/Core/src/Platform/Android/SafeAreaExtensions.cs), 0 test files (existing test Issue33034 already in main)

Key Findings

• Issue: When switching Shell tabs on Android in landscape mode, safe area padding is applied correctly on the first tab but not on subsequent tabs. Content collides with display cutout.
• Root cause: During Shell tab navigation animations, views move off-screen (e.g., viewLeft < 0). The old code applied Math.Max(0, viewLeft - margins) BEFORE detecting animation state, which clamped negative viewLeft to 0. This destroyed the signal used to detect that the view was still animating.
• On API 36, this timing issue was more pronounced: viewLeft=-1 was clamped to 0 by Math.Max, then the animation check (viewIsAnimatingHorizontally) found viewLeft > 0 was false and incorrectly concluded the view was settled, applying reduced safe area padding too early.
• The PR fix moves animation detection BEFORE margin adjustment, ensuring raw position values are used to detect off-screen state.
• Also reorders left/right edge checks to evaluate animation FIRST, preventing partial padding from being applied near end of animation.
• Existing test SafeAreaShouldWorkOnAllShellTabs (Issue33034.cs) validates the fix: switches between tabs and asserts EdgeLabel X position and width are consistent.
• Prior agent review at commit 69496bd resulted in s/agent-changes-requested label; current HEAD is 39ebc45 with subsequent commits addressing feedback.
• One resolved inline review comment (typo fix "hasn't happen yet" → "hasn't happened yet") — the PR author appears to have addressed this (comment is resolved/outdated).

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34239	Move viewIsAnimatingHorizontally detection before Math.Max(0, ...) margin clamping; reorder left/right edge animation checks before overlap checks; rename flags for clarity	⏳ PENDING (Gate skipped — no new tests in PR)	SafeAreaExtensions.cs	Original PR; prior agent review requested changes

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Early short-circuit: detect animation from raw coords before any margin adjustment; keep full safe area for ALL edges when animating; skip per-edge overlap calc entirely	✅ PASS	SafeAreaExtensions.cs	Two code paths (animating vs settled); most structural change
2	try-fix (claude-sonnet-4.6)	Geometric settled-position projection: remove Math.Max(0,...) clamp; project off-screen coords to settled position (checkLeft, checkRight); no animation booleans	✅ PASS	SafeAreaExtensions.cs	Elegant but subtle; removes animation flag documentation
3	try-fix (gpt-5.3-codex)	Deferred margin adjustment: keep raw coordinates immutable; apply margins inline within each edge overlap calculation	✅ PASS	SafeAreaExtensions.cs	Good principle; inline margin math reduces readability
4	try-fix (gpt-5.4)	Raw-coordinate snapshot: capture rawViewLeft/rawViewRight BEFORE Math.Max(0,...) mutation; use raw values for animation detection; keep existing clamping and overlap flow	✅ PASS	SafeAreaExtensions.cs	Most minimal; nearly identical to PR approach
PR	PR #34239	Move viewIsAnimatingHorizontally detection before Math.Max margin clamping; use viewLeft < 0 || viewRight > screenWidth; reorder left/right edge checks — animation first, then overlap	⏳ PENDING (Gate skipped)	SafeAreaExtensions.cs	Well-commented; conceptually clean; targeted

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	No	"NO NEW IDEAS — five approaches cover the viable solution space across all design axes"

Exhausted: Yes
Selected Fix: PR #34239's fix — All 4 independent attempts converge on the same root cause. The PR's approach mirrors Attempt 4 (raw snapshot) and adds conceptually cleaner reordering of animation-check-before-overlap for left/right edges. Most readable, well-commented, and matches codebase style. Single file, +47/-44 lines.

---

📋 Report — Final Recommendation

---

✅ Final Recommendation: APPROVE

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Issue #33034, Android landscape safe area regression
Gate	⚠️ SKIPPED	No new tests added in this PR; existing test Issue33034.SafeAreaShouldWorkOnAllShellTabs already covers the scenario
Try-Fix	✅ COMPLETE	4 attempts, 4 passing; cross-pollination exhausted
Report	✅ COMPLETE

Summary

PR #34239 fixes a safe area padding regression on Android API 36 when switching Shell tabs in landscape mode with a display cutout. The fix is logically sound — all 4 independent try-fix models converged on the same root cause understanding and each produced a passing alternative, confirming the PR author's diagnosis is correct. The PR's chosen approach is the cleanest and best-documented of the five solutions.

Root Cause

Math.Max(0, viewLeft - margins) in ApplyAdjustedSafeAreaInsetsPx was being applied before the animation state detection. When a view was mid-animation with viewLeft = -1 (just off-screen left), the clamp set viewLeft = 0, making viewIsAnimatingHorizontally impossible to detect — the view was then treated as settled and safe area padding was reduced too early, causing a visible padding jump on tab switch.

Fix Quality

Correct and well-targeted. The PR:

1. Moves viewIsAnimatingHorizontally = viewLeft < 0 || viewRight > screenWidth detection before the Math.Max(0, ...) clamp — preserving animation signals from raw position values ✅
2. Renames viewIsAnimating → viewIsAnimatingVertically/viewIsAnimatingHorizontally — clarity improvement ✅
3. Reorders left/right edge checks to evaluate animation before overlap — prevents partial-inset application near end of animation ✅
4. Addressed prior review feedback (typo "hasn't happen yet" → "hasn't happened yet" fixed) ✅

Logic verified: When viewLeft < 0 → clamped to 0 → viewIsAnimatingHorizontally && viewLeft > 0 = false → falls to viewLeft < left (0 < left) → Math.Min(left - 0, left) = left — full inset preserved correctly.

One minor observation: The right-edge animation guard (if (right > 0 && viewIsAnimatingHorizontally)) fires even when only viewLeft < 0 triggered the flag (view off-screen left). This is acceptable: the view is about to settle at X=0 where viewRight ≈ screenWidth, so applying the full right inset during animation is correct behavior.

No new tests added — the existing SafeAreaShouldWorkOnAllShellTabs test (Issue33034.cs) covers the regression. Authors validated it locally on API 36. CI should run this test to confirm.

Selected Fix: PR

---

[kubaflo]

Could you please review the AI's summary?

[praveenkumarkarunanithi]

🤖 AI Summary

📊 Expand Full Review — 69496bd · Update src/Core/src/Platform/Android/SafeAreaExtensions.cs
🔍 Pre-Flight — Context & Validation
Issue: #33034 - SafeAreaEdges works correctly only on the first tab in Shell. Other tabs have content colliding with the display cutout in the landscape mode. PR: #34239 - [Android] Fix SafeAreaShouldWorkOnAllShellTabs test failure on API 36 Platforms Affected: Android (landscape mode with display cutout/notch) Files Changed: 1 implementation (SafeAreaExtensions.cs), 0 test files (test already exists in main)

Key Findings

• Issue: When switching Shell tabs on Android in landscape mode, safe area padding is applied incorrectly on non-first tabs because animation detection is broken after margin clamping
• Root cause (per PR): Math.Max(0, viewLeft - margins.Left) was applied BEFORE checking viewLeft < 0, clamping the negative animation signal to 0 and making it impossible to detect off-screen horizontal animation
• PR fix: Moves animation detection (viewIsAnimatingHorizontally) BEFORE the margin adjustment block, using raw position values
• PR also reorders left/right edge checks to prioritize animation detection over overlap detection
• Old viewIsAnimatingHorizontally = viewLeft > 0 && (viewRight > screenWidth || viewBottom > screenHeight) — didn't detect viewLeft < 0 case
• New viewIsAnimatingHorizontally = viewLeft < 0 || viewRight > screenWidth — correctly detects both left-off-screen and right-off-screen
• Gate: ❌ FAILED on Android — the test SafeAreaShouldWorkOnAllShellTabs did NOT pass with PR's fix
• Test file: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33034.cs
• Host app: src/Controls/tests/TestCases.HostApp/Issues/Issue33034.cs
• One inline review comment from Copilot about a grammar typo (resolved/outdated)

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #34239 Move animation detection before margin clamping; split into horizontal/vertical flags; reorder left/right checks ❌ FAILED (Gate) SafeAreaExtensions.cs Original PR fix
🔧 Fix — Analysis & Comparison

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #34239 Move animation detection before margin clamping; reorder left/right checks ❌ FAILED (Gate) SafeAreaExtensions.cs Original PR — gate failed
1 try-fix (claude-opus-4.6) Save rawViewLeft/rawViewRight before margin clamping; use as first condition in left/right edge checks ✅ PASS SafeAreaExtensions.cs Keeps original code order; explicit raw values
2 try-fix (claude-sonnet-4.6) HasTransientState + parent walk (5 levels) + raw fallback ✅ PASS SafeAreaExtensions.cs Android animation framework detection
3 try-fix (gpt-5.3-codex) Remove Math.Max(0,...) clamp on viewLeft — 1-line fix ✅ PASS SafeAreaExtensions.cs (+1/-1) Minimal; overlap math handles negative naturally
4 try-fix (gpt-5.4) Left-edge hysteresis: keep full inset when tracked view reports viewLeft ≤ 5px ✅ PASS SafeAreaExtensions.cs Per-tracked-view heuristic
5 cross-poll r2 (claude-opus-4.6) Walk parents checking Math.Abs(view.TranslationX) > 0.5f ✅ PASS SafeAreaExtensions.cs (+34/-15) Direct fragment animation signal
6 cross-poll r2 (claude-sonnet-4.6) Replace GetLocationOnScreen() with view.Left/view.Top parent-walk — removes ALL animation detection ✅ PASS SafeAreaExtensions.cs (+16/-52) Root-cause fix; cleanest architecture
7 cross-poll r2 (gpt-5.3-codex) Frame-stability gate via ViewTreeObserver.OnPreDraw + SetTag; defer horizontal padding until 2 consecutive passes agree ✅ PASS SafeAreaExtensions.cs (+124) Complex; detects motion itself
8 cross-poll r2 (gpt-5.4) ConditionalWeakTable<View, PaddingCache>; preserve prior padding when bounds moved ≥2px; post RequestApplyInsets() ✅ PASS SafeAreaExtensions.cs Deferral approach; per-view state

Cross-Pollination

Model Round New Ideas? Details
claude-opus-4.6 2 YES view.TranslationX parent walk → Attempt 5
claude-sonnet-4.6 2 YES view.Left/view.Top parent-walk → Attempt 6
gpt-5.3-codex 2 YES Frame-stability gate via OnPreDraw → Attempt 7
gpt-5.4 2 YES ConditionalWeakTable padding cache + defer → Attempt 8
All models 3 ⏳ PENDING Round 3 exhaustion check
| 9 | cross-poll r3 (claude-sonnet-4.6) | view.Matrix?.IsIdentity == false — O(1) composite matrix check; full insets when any transform active; removes all coordinate heuristics | ✅ PASS | SafeAreaExtensions.cs (~30 changed) | Elegant O(1) check; reads actual rendering state |

Cross-Pollination

Model Round New Ideas? Details
claude-opus-4.6 2 YES view.TranslationX parent walk → Attempt 5
claude-sonnet-4.6 2 YES view.Left/view.Top parent-walk → Attempt 6
gpt-5.3-codex 2 YES Frame-stability gate via OnPreDraw → Attempt 7
gpt-5.4 2 YES ConditionalWeakTable padding cache + defer → Attempt 8
claude-opus-4.6 3 NO Exhausted
claude-sonnet-4.6 3 YES view.Matrix.IsIdentity → Attempt 9
gpt-5.3-codex 3 YES (skipped) WindowInsetsAnimationCompat.Callback — overlaps Attempt 7/8 deferral pattern; IME-focused, not applicable to Shell fragment transitions
gpt-5.4 3 YES (skipped) Animation/LayoutTransition walk+freeze — overlaps Attempts 2/5 animation-state detection
Exhausted: Yes (max 3 rounds reached)

Selected Fix: Candidate #6 (claude-sonnet-4.6 cross-poll round 2) — Replace GetLocationOnScreen() with view.Left/view.Top parent-walk layout position.

Comparison table:

Candidate Simplicity Robustness Style Verdict
PR (FAILED) Medium ❌ Fails Good Rejected
#3 (remove clamp) ⭐ 1-line ⚠️ May break margin+SA additivity Good Runner-up
#6 (parent-walk pos.) ⭐ Net -52 lines ✅ Eliminates root cause ⭐ Best Winner
#9 (Matrix.IsIdentity) Good ✅ O(1), direct Good Strong #2
#7, #8 (defer/cache) ❌ Complex ✅ Correct Over-engineered Rejected
Reason: Attempt 6 addresses the true root cause (unstable position source) rather than detecting and branching on animation state. It removes ~52 lines net, eliminates all animation detection heuristics, and produces a simpler, more maintainable result. The parent-walk correctly returns the layout-assigned position regardless of in-flight animator transforms.

📋 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase Status Notes
Pre-Flight ✅ COMPLETE Issue #33034, 1 file changed, Android landscape Shell tab animation
Gate ❌ FAILED Android — SafeAreaShouldWorkOnAllShellTabs did not pass with PR's fix
Try-Fix ✅ COMPLETE 9 attempts, 8 passing (PR rejected), 1 selected winner
Report ✅ COMPLETE

Summary

PR #34239 attempts to fix incorrect safe area padding on non-first Shell tabs in Android landscape mode (issue #33034). The fix was validated locally by the author but failed the automated gate test on API 36. Try-Fix exploration found 8 working alternative approaches, with a clear winner that is simpler and more architecturally sound than the PR's approach.

Root Cause

During Shell tab navigation transitions, Android's fragment animator applies TranslationX/TranslationY to the fragment container via setTranslationX(). The existing GetLocationOnScreen() call returns the view's visual (animated) position — including in-flight transform offsets — rather than the layout-assigned position. This causes the safe area overlap calculation to see intermediate positions (e.g., viewLeft = -1, clamped to 0 after Math.Max(0, ...)) and emit incorrect padding values that persist after the animation settles.

The PR's fix correctly identified that margin clamping (Math.Max(0, viewLeft - margins.Left)) was destroying the negative-position animation signal, but its reordering and new flag logic (viewLeft < 0 || viewRight > screenWidth) still failed the test — likely due to a remaining edge case in the reordered left-edge conditional logic.

Fix Quality

PR's fix: ⚠️ Partial/incomplete. The direction is correct (detect viewLeft < 0) but the implementation has a logic flaw — the gate confirms the test still fails after applying the PR. Specifically, the reordered left-edge check if (left > 0 && viewIsAnimatingHorizontally && viewLeft > 0) adds a viewLeft > 0 guard that excludes the case where viewLeft == 0 (which occurs after viewLeft = -1 gets clamped). This means animation is not detected for that precise frame.

Best alternative (Attempt 6 — ✅ PASS): Replace GetLocationOnScreen() with a view.Left/view.Top parent-walk that sums layout-assigned coordinates. Layout positions are set during the layout pass and are never mutated by animator interpolation — no animation detection heuristics are needed at all. This approach:

• Removes ~52 lines net (eliminates all animation detection code)
• Fixes the root cause rather than working around it
• Is simpler, cleaner, and more maintainable
• Passed the test on first run

Runner-up (Attempt 3 — ✅ PASS): Remove Math.Max(0, ...) clamp on viewLeft: change viewLeft = Math.Max(0, viewLeft - ...) to viewLeft -= .... One-line change. When viewLeft = -1, it stays -1 after margin adjustment, and left < left still evaluates correctly. However, this may break the "margins and safe area are additive" contract in edge cases where margin subtraction produces a negative position that was genuinely intended to be zero.

Suggested Change for PR Author

Replace GetLocationOnScreen() with a layout-position parent-walk:

// Get view's layout-assigned position by walking the parent hierarchy.
// Using GetLocationOnScreen() includes in-flight animator TranslationX/Y,
// producing unstable positions during Shell tab transitions.
int layoutLeft = 0, layoutTop = 0;
View? cursor = view;
while (cursor != null && !(cursor.Parent is global::Android.Views.Window))
{
    layoutLeft += cursor.Left;
    layoutTop += cursor.Top;
    cursor = cursor.Parent as View;
}
var viewLeft = layoutLeft;
var viewTop = layoutTop;

Then remove viewIsAnimating, viewIsAnimatingVertically, and viewIsAnimatingHorizontally — they are no longer needed.

Selected Fix: Candidate #6 (parent-walk layout position) — not the PR's fix

The AI-suggested parent-walk approach was implemented and tested locally on an API 36 emulator — it does not fix the issue. The gate failure is due to CI not supporting API 36;