[iOS] Fix SafeArea infinite layout cycle with parent hierarchy walk and pixel-level comparison

[PureWeen]

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

SafeAreaInsetsDidChange fires repeatedly during iOS animations (e.g., TranslateToAsync, bottom sheet transitions) as views move relative to the window. This caused two distinct infinite loop patterns:

1. Sub-pixel oscillation (Layout issue using TranslateToAsync causes infinite property changed cycle on iOS #32586, [iOS] TranslateToAsync causes spurious SizeChanged events after animation completion, triggering infinite layout loops #33934): Animations produce sub-pixel differences in SafeAreaInsets (e.g., 0.0000001pt). Exact equality fails, triggering InvalidateAncestorsMeasures → layout pass → position change → new SafeAreaInsetsDidChange → infinite loop.

2. Parent-child double application ([net10] iOS 18.6 crashing on navigating to a ContentPage with Padding set and Content set to a <Grid RowDefinitions="*,Auto"> with ScrollView on row 0 #33595): A ContentPage (implementing ISafeAreaView) and its child Grid both independently apply safe area adjustments. When the ContentPage adjusts its layout for the notch/status bar, it repositions the Grid. The Grid's new position fires SafeAreaInsetsDidChange, causing it to re-apply its own adjustment — creating a ping-pong loop.

Description of Change

Primary fix — IsParentHandlingSafeArea (parent hierarchy walk):

In both MauiView.ValidateSafeArea and MauiScrollView.ValidateSafeArea, before applying safe area adjustments, we now check whether an ancestor MauiView is already applying safe area for the same edges. If so, the child skips its own adjustment to avoid double-padding.

The check is edge-aware: a parent handling Top does not block a child from independently handling Bottom. Only overlapping edges cause deferral. The _parentHandlesSafeArea result is cached per layout cycle and cleared on SafeAreaInsetsDidChange, InvalidateSafeArea, and MovedToWindow.

Secondary fix — EqualsAtPixelLevel:

Safe area values are compared at device-pixel resolution (rounding to 1 / ContentScaleFactor) before deciding whether to trigger a layout invalidation. This absorbs sub-pixel animation noise and prevents the oscillation loops in #32586 and #33934.

MauiScrollView bug fixes:

• Inverted condition: !UpdateContentInsetAdjustmentBehavior() was incorrectly gating behavior; corrected to UpdateContentInsetAdjustmentBehavior().
• The _appliesSafeAreaAdjustments flag now correctly incorporates !IsParentHandlingSafeArea().

What was removed:

• The "Window Guard" approach (comparing Window.SafeAreaInsets to filter noise) was tried and removed. It was fragile: on macCatalyst with a custom TitleBar, WindowViewController repositions content by pushing it down, which changes the view's own SafeAreaInsets without changing Window.SafeAreaInsets. The guard blocked this legitimate change, causing a 28px content shift regression in CI.

Issues Fixed

Fixes #32586
Fixes #33934
Fixes #33595
Fixes #34042

[Copilot]

Pull request overview

This PR fixes an iOS infinite layout cycle that occurs when nested views both have SafeAreaEdges = Container by implementing a generation counter mechanism to track SafeArea change events.

Changes:

• Implemented a generation counter system using a static counter incremented on genuine SafeArea changes and per-view tracking to prevent re-invalidation within the same generation
• Added test cases for nested SafeArea views with animations (Issue32586) and runtime SafeAreaEdges toggling (Issue33595)

Reviewed changes

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

Show a summary per file

File	Description
src/Core/src/Platform/iOS/MauiView.cs	Added generation counter fields and logic to break infinite layout cycles in LayoutSubviews
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33595.cs	UI test verifying navigation with padding and ScrollView doesn't crash
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32586.cs	UI tests for TranslateToAsync animation and runtime SafeAreaEdges toggling
src/Controls/tests/TestCases.HostApp/Issues/Issue33595.cs	Test page with Grid containing ScrollView that previously caused freezing
src/Controls/tests/TestCases.HostApp/Issues/Issue32586.cs	Test page with nested SafeArea views and animation triggers

[PureWeen]

Test Results ✅

Successfully fixed the infinite layout cycle! The fix now passes all tests:

Issue32586 Test (the freeze repro)

• Before: App froze indefinitely, test hung forever
• After: Test passes ✅

All SafeAreaEdges Tests

• Result: All passed ✅

How the Fix Works

The root cause was that InvalidateMeasure() sets _safeAreaInvalidated = true on ancestor views. This caused ValidateSafeArea() to run again on the next LayoutSubviews even when safe area values hadn't changed, creating a cycle.

The fix uses a global generation counter that increments each time any view invalidates ancestors from LayoutSubviews. Each view tracks the generation at which it last invalidated. If asked to layout again at the same generation (we're in a cycle), it skips the invalidation.

This preserves correct SafeArea behavior while breaking the infinite loop.

Bonus: Test Infrastructure Improvements

Also added resilience fixes to prevent tests from hanging indefinitely when apps freeze:

1. Process-level timeout in BuildAndRunHostApp.ps1 (5 minutes)
2. Property getter timeouts for GetText/GetAttribute/GetRect/IsSelected
3. Teardown timeouts for App.AppState queries

These ensure tests fail gracefully instead of hanging, making it much easier to debug layout issues like this one.

[PureWeen]

/rebase

[PureWeen]

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

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

Alright @Tamilarasan-Paranthaman @sheiksyedm

Let me know what you think of this fix

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

🔬 Fix Approach Comparison — 4 Independent Attempts

We ran 4 independent try-fix attempts, each proposing a fundamentally different approach to fix the iOS safe area infinite layout cycle. After retesting with the updated UITests (with [Order] attributes and state-reset logic), only Approach 3 passes all tests.

Retest Results (Updated UITests)

#	Approach	Filters By	Issue32586 (3 tests)	Issue33934	Overall
1	Epsilon tolerance	VALUE	❌ 2/3	❌ FAIL	❌ FAIL
2	Layout guard	CONTEXT	❌ 2/3	✅ PASS	⚠️ Partial
3	Window-level comparison	SOURCE	✅ 3/3	✅ PASS	✅ PASS
4	Time-based debounce	TIME	❌ 2/3	❌ FAIL	❌ FAIL

Common failure in approaches 1, 2, 4: VerifyFooterPositionRespectsSafeArea — footer stays ~33pt above screen bottom despite SafeAreaEdges=None, proving safe area is still being applied incorrectly.

✅ Selected: Approach 3 — Window-Level Safe Area Comparison (applied in 3498ef8)

All approaches also fix a pre-existing bug in MauiScrollView.cs where _safeAreaInvalidated = true should be _safeAreaInvalidated = false in ValidateSafeArea() (the flag was never being cleared after validation).

---

✅ Approach 3: Window-Level Comparison (SELECTED — filters by SOURCE)

Concept

Compare Window.SafeAreaInsets (device-level: status bar, home indicator) in SafeAreaInsetsDidChange(). During animations, a view's own SafeAreaInsets fluctuate, but Window.SafeAreaInsets stay constant. If Window insets haven't changed, the event is animation noise → skip it entirely.

Why it works

• [iOS] TranslateToAsync causes spurious SizeChanged events after animation completion, triggering infinite layout loops #33934: During TranslateToAsync, Window.SafeAreaInsets doesn't change → early return → _safeAreaInvalidated stays false → no invalidation cascade.
• Layout issue using TranslateToAsync causes infinite property changed cycle on iOS #32586: No rounding = no risk of rounding artifacts on zero values. Animation-induced SafeAreaInsetsDidChange is filtered → no spurious invalidation.

Changes

• MauiView.cs: Added _lastWindowSafeAreaInsets field, Window comparison in SafeAreaInsetsDidChange(), reset in MovedToWindow()
• MauiScrollView.cs: Same pattern + _safeAreaInvalidated bug fix + MovedToWindow() reset

Key code

UIEdgeInsets _lastWindowSafeAreaInsets;

public override void SafeAreaInsetsDidChange()
{
    if (Window is not null)
    {
        var windowInsets = Window.SafeAreaInsets;
        if (windowInsets == _lastWindowSafeAreaInsets)
            return;
        _lastWindowSafeAreaInsets = windowInsets;
    }
    _safeAreaInvalidated = true;
    base.SafeAreaInsetsDidChange();
}

Pros

• Semantically clear: filters by the SOURCE of truth for device safe areas
• No magic numbers, no structural changes
• Only genuine safe area events (rotation, keyboard, status bar) pass through
• Keyboard events handled separately via OnKeyboardWillShow/Hide

Cons

• Assumes Window.SafeAreaInsets never changes during animations (should hold but is UIKit implementation detail)
• Requires MovedToWindow() override to reset cached value

❌ Approach 1: Epsilon-Based Tolerance (FAILED retest — filters by VALUE)

Concept

Use epsilon-based tolerance comparison (0.5pt) to absorb sub-pixel noise from animations. Values that differ by less than epsilon are treated as unchanged.

Retest Result

• Issue32586: ❌ VerifyFooterPositionRespectsSafeArea failed — footer 33pt short of screen bottom
• Issue33934: ❌ Timed out — infinite animation loop not prevented

Why it failed

Epsilon comparison only filters sub-pixel noise at the value level but doesn't prevent the SafeAreaInsetsDidChange callback from firing and setting _safeAreaInvalidated = true. The safe area values can still differ by more than epsilon during animations.

⚠️ Approach 2: Layout Guard (PARTIAL — filters by CONTEXT)

Concept

Track when inside LayoutSubviews() with _isInLayoutSubviews flag. Skip ancestor invalidation during layout passes.

Retest Result

• Issue32586: ❌ VerifyFooterPositionRespectsSafeArea failed — footer 33pt short of screen bottom
• Issue33934: ✅ PASS — animation completes

Why it partially failed

The layout guard prevents the infinite cycle (33934 passes) but doesn't prevent safe area values from being applied when they shouldn't be. The flag only gates invalidation, not the safe area calculation itself.

❌ Approach 4: Time-Based Debounce (FAILED retest — filters by TIME)

Concept

Coalesce rapid SafeAreaInsetsDidChange calls using a 16ms debounce window (~1 frame).

Retest Result

• Issue32586: ❌ VerifyFooterPositionRespectsSafeArea failed — footer 33pt short of screen bottom
• Issue33934: ❌ Timed out — infinite animation loop not prevented

Why it failed

Time-based filtering still allows the first SafeAreaInsetsDidChange per frame through, which is enough to trigger the invalidation cycle. The problem isn't rate-of-change but that animation-induced changes shouldn't trigger invalidation at all.

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[PureWeen]

/azp run maui-pr-uitests

[PureWeen]

/azp run maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[PureWeen]

/azp run maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[PureWeen]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).