[iOS] MauiView: Round SafeArea insets to pixels to fix infinite layout cycle

[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

TranslateToAsync animations on iOS cause SafeAreaInsetsDidChange to fire repeatedly as the view moves relative to the window. These updates often contain sub-pixel differences (e.g., 0.0000001pt). Because SafeAreaPadding uses double precision, exact equality checks fail (oldSafeArea == newSafeArea returns false), triggering:

1. InvalidateAncestorsMeasures
2. Layout pass
3. Position change
4. New SafeAreaInsetsDidChange event
5. Infinite Loop (app freeze)

Description of Change

In MauiView.ValidateSafeArea and MauiScrollView.ValidateSafeArea, we now round the safe area insets to the nearest device pixel using ContentScaleFactor.

This stabilizes the values by absorbing sub-pixel oscillation into the same pixel bucket. The comparison oldSafeArea == newSafeArea now returns true for sub-pixel changes, preventing unnecessary layout invalidation and breaking the cycle.

Refinements:

• Used ContentScaleFactor instead of Window.Screen.Scale for safer access.
• Applied fix to MauiScrollView to prevent latent cycles there.
• Reverted previous complex fixes (Window guard, isPropagating guard, cycle-break flag) in favor of this simpler, more robust solution.

Issues Fixed

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

Platforms Tested

• iOS (Validated with new regression tests)
• Android
• Windows
• Mac

[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

[Copilot]

The static counter s_safeAreaGeneration is accessed from multiple threads (read in LayoutSubviews() at line 565 and incremented atomically in SafeAreaInsetsDidChange() at line 730), but the read operation is not atomic. Consider using Interlocked.Read() or Volatile.Read() when accessing this counter to ensure thread-safe reads.

Suggested change

	static int s_safeAreaGeneration;
	static volatile int s_safeAreaGeneration;

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