[iOS] Flyout Items Not Displayed in RightToLeft FlowDirection in Landscape - fix

[kubaflo]

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 PhoneFlyoutPageRenderer.LayoutChildren(), when IsRTL && !FlyoutOverlapsDetailsInPopoverMode, the flyout panel's X position was calculated as:

flyoutFrame.X = (int)(flyoutFrame.Width * .25);

This formula positions the flyout at 25% of its own width from the left edge — not at the right side of the screen. In landscape orientation (where frame.Width is large), this places the flyout far off to the left, making its content invisible or clipped rather than right-aligned as expected for RTL layout.

Description of Change

PhoneFlyoutPageRenderer.cs — 1-line fix:

// Before
flyoutFrame.X = (int)(flyoutFrame.Width * .25);

// After
flyoutFrame.X = (int)(frame.Width - flyoutFrame.Width);

frame.Width - flyoutFrame.Width is the standard right-align formula: it positions the flyout so its right edge aligns with the screen's right edge, which is the correct position for an RTL flyout panel.

Issue2818.cs (test) — two changes:

1. Removed TEST_FAILS_ON_IOS compile guard. The test was previously skipped on iOS because the RTL flyout was broken. The fix makes iOS behavior correct, so the guard is no longer needed.

2. Added RootViewSizeDoesntChangeAfterBackground test (async) with a polling loop (up to 5s / 50 × 100ms) to wait for window size to stabilize after backgrounding/foregrounding the app. This prevents flakiness caused by intermediate layout sizes during window restoration on iOS.

Issues Fixed

Fixes #26726

Platforms Tested

• iOS (primary — fix targets iOS RTL landscape flyout behavior)
• Android (not affected — PhoneFlyoutPageRenderer is iOS-only)
• Windows (not affected)
• Mac Catalyst (test still excluded via TEST_FAILS_ON_CATALYST guard)

Details

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

Could you include a test? Let me know if needs something.

[kubaflo]

Could you include a test? Let me know if needs something.

Done :)

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jfversluis]

/rebase

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[kubaflo]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Stabilize window size check in Issue2818 test · bef57ff

---

Issue: #26726 - Flyout Items Not Displayed in RightToLeft FlowDirection on iOS in Landscape Orientation and Hamburger Icon Positioned Incorrectly
PR: #26762 - [iOS] Flyout Items Not Displayed in RightToLeft FlowDirection in Landscape - fix
Platforms Affected: iOS only
Files Changed: 1 implementation file, 1 test file

Issue Summary

When FlowDirection is set to RightToLeft on a FlyoutPage, in landscape orientation on iOS:

• The flyout items are not visible when the flyout is opened
• The hamburger menu icon appears on the left instead of the right

Fix Analysis

File: src/Controls/src/Core/Compatibility/Handlers/FlyoutPage/iOS/PhoneFlyoutPageRenderer.cs

-flyoutFrame.X = (int)(flyoutFrame.Width * .25);
+flyoutFrame.X = (int)(frame.Width - flyoutFrame.Width);

In LayoutChildren(), when IsRTL && !FlyoutOverlapsDetailsInPopoverMode, the flyout's X position was being set to 25% of the flyout width. This means in landscape (wider screen), the flyout was being positioned off-screen or at an incorrect location. The fix correctly aligns the flyout to the right edge: frame.Width - flyoutFrame.Width.

Test Changes

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/XFIssue/Issue2818.cs

• Removed TEST_FAILS_ON_IOS compile guard, enabling the test to run on iOS
• Added new async test RootViewSizeDoesntChangeAfterBackground with a polling loop (up to 50100ms) to wait for window size to stabilize after backgrounding/foregrounding the app

Reviewer Discussion

Reviewer	Comment	Status
jsuarezruiz	Requested test be added Resolved - test added
jfversluis	Asked about Task.Delay usage Resolved - author used polling loop instead

Potential Concerns

• The [Issue] attribute in TestCases.HostApp/Issues/XFIssue/Issue2818.cs has PlatformAffected.Android though the issue is iOS-specific. The test itself runs on iOS (the #if guard condition controls platform).
• The polling loop in RootViewSizeDoesntChangeAfterBackground (50100ms max = 5s) is a valid pattern per UITest guidelines.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #26762	Correct flyout X position in RTL+landscape: `frame.Width - flyoutFrame. PENDING (Gate)	PhoneFlyoutPageRenderer.cs (+1/-1)	Original PR	Width`

---

🚦 Gate — Test Verification

---

📝 Review Session — Stabilize window size check in Issue2818 test · bef57ff

---

** PARTIAL - Environment IssueResult:**
Platform: ios
Mode: Full Verification

Test Results

Check	Expected	Actual	Result
Tests WITHOUT fix	FAIL	FAIL
Tests WITH fix	PASS		FAIL

Detailed Results (WITH fix)

• RootViewMovesAndContentIsVisible - PASSED [4 sec] - This test directly validates the RTL flyout positioning fix
  RootViewSizeDoesntChangeAfterBackground - FAILED [5 sec] - TearDown error: Unable To Rotate Device-
• LabelWithPaddingIsNotTruncated - PASSED [545 ms]

Analysis

The Gate failure is due to an environment issue in TearDown, NOT a failure of the fix itself:

1. The test body of RootViewSizeDoesntChangeAfterBackground appears to have passed (no assertion error was thrown - only TearDown failed)
2. The TearDown calls App.SetOrientationPortrait() which throws OpenQA.Selenium.UnknownErrorException : Unable To Rotate Device - this is an iOS 26 simulator infrastructure issue
3. The primary test (which directly tests the RTL flyout visibility bug) PASSED

Conclusion

Gate is marked as FAILED due to the environment-related TearDown rotation issue. The fix behavior itself appears correct based on the primary test passing.

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Stabilize window size check in Issue2818 test · bef57ff

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #26762	Correct flyout X position in RTL+landscape:	, TearDown env	PhoneFlyoutPageRenderer.cs (+1/-1)	Original PR

Exhausted: N/A - Fix phase skipped (Gate failed due to environment issue)
Selected Fix: PR's fix - Gate failure was due to an environment/infrastructure issue (iOS simulator Unable To Rotate Device in TearDown), not a failure of the fix logic. Primary test RootViewMovesAndContentIsVisible PASSED.

Reason for Skipping Fix Phase

Gate failed with . Per autonomous execution rules, when Gate fails due to environment issues, the Fix phase is skipped and we proceed to Report. The primary test () that directly validates the RTL flyout positioning bug PASSED .

---

📋 Report — Final Recommendation

---

📝 Review Session — Stabilize window size check in Issue2818 test · bef57ff

---

Final Recommendation: APPROVE

Summary

PR #26762 fixes a 1-line bug in PhoneFlyoutPageRenderer.cs that caused the flyout panel to be incorrectly positioned when FlowDirection is RightToLeft in landscape orientation on iOS. The fix is correct, minimal, and the primary validation test passed.

Root Cause

In LayoutChildren(), the RTL flyout X position was calculated as:

flyoutFrame.X = (int)(flyoutFrame.Width * .25);

This formula doesn't position the flyout at the right edge of the screen. In landscape mode (e.g., frame.Width=844, flyoutFrame.Width=312), this gives X= placing the flyout partially overlapping the content from the left side, making flyout items appear hidden.78

The fix correctly calculates the right-aligned position:

flyoutFrame.X = (int)(frame.Width - flyoutFrame.Width);

This positions the flyout so its right edge aligns with the screen's right edge (X=532 for the example above), which is the correct RTL behavior.

Fix Quality

Implementation (PhoneFlyoutPageRenderer.cs Excellent):

• Minimal 1-line change in exactly the right location
• Mathematically correct: frame.Width - flyoutFrame.Width is the standard formula for right-aligning an element
• No side effects on other code paths (only applies when IsRTL && !FlyoutOverlapsDetailsInPopoverMode)

Tests (Issue2818.cs Good):

• Correctly removes TEST_FAILS_ON_IOS from the compile guard, enabling the existing RootViewMovesAndContentIsVisible test on iOS
• Adds RootViewSizeDoesntChangeAfterBackground to validate post-background stability
• Uses polling loop (50100ms max) which is a valid UITest pattern

Test Results

Test	Status	Notes
	PASSED	Primary test: validates RTL flyout visibility
` TearDown env error	Test body likely passed; TearDown rotation fails on iOS 26 simulator	RootViewSizeDoesntChangeAfterBackground`

Gate Environment issue with iOS 26 simulator rotation in TearDown, NOT a fix regression.PARTIAL Status:

Minor Issue Found

The [Issue] attribute in TestCases.HostApp/Issues/XFIssue/Issue2818.cs has PlatformAffected.Android but the bug affects iOS. This doesn't affect test execution (the #if guard controls compilation) but is semantically incorrect. Not a blocker.

PR Title & Description Assessment

• Title:
• Description: Links to issue, includes before/after videos. Minimal but adequate.

Reviewer Feedback Addressed

• jsuarezruizs request for tests Tests added:
• jfversluiss question about delays Resolved with polling loop approach:

Conclusion

The fix is correct and well-targeted. The Gate failure is due to an iOS 26 simulator environment issue with the rotation call (), not a problem with the fix itself. The test that directly validates the reported bug () PASSED . This PR should be approved.

---

📋 Expand PR Finalization Review

---

Title: ⚠️ Needs Update

Current: [iOS] Flyout Items Not Displayed in RightToLeft FlowDirection in Landscape - fix

Recommended: follows the

Description: ❌ Needs Rewrite

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 PhoneFlyoutPageRenderer.LayoutChildren(), when IsRTL && !FlyoutOverlapsDetailsInPopoverMode, the flyout panel's X position was calculated as:

flyoutFrame.X = (int)(flyoutFrame.Width * .25);

This formula positions the flyout at 25% of its own width from the left edge — not at the right side of the screen. In landscape orientation (where frame.Width is large), this places the flyout far off to the left, making its content invisible or clipped rather than right-aligned as expected for RTL layout.

Description of Change

PhoneFlyoutPageRenderer.cs — 1-line fix:

// Before
flyoutFrame.X = (int)(flyoutFrame.Width * .25);

// After
flyoutFrame.X = (int)(frame.Width - flyoutFrame.Width);

frame.Width - flyoutFrame.Width is the standard right-align formula: it positions the flyout so its right edge aligns with the screen's right edge, which is the correct position for an RTL flyout panel.

Issue2818.cs (test) — two changes:

1. Removed TEST_FAILS_ON_IOS compile guard. The test was previously skipped on iOS because the RTL flyout was broken. The fix makes iOS behavior correct, so the guard is no longer needed.

2. Added RootViewSizeDoesntChangeAfterBackground test (async) with a polling loop (up to 5s / 50 × 100ms) to wait for window size to stabilize after backgrounding/foregrounding the app. This prevents flakiness caused by intermediate layout sizes during window restoration on iOS.

Issues Fixed

Fixes #26726

Platforms Tested

• iOS (primary — fix targets iOS RTL landscape flyout behavior)
• Android (not affected — PhoneFlyoutPageRenderer is iOS-only)
• Windows (not affected)
• Mac Catalyst (test still excluded via TEST_FAILS_ON_CATALYST guard)

Code Review: ⚠️ Issues Found

Code Review — PR #26762

✅ Looks Good

PhoneFlyoutPageRenderer.cs — Implementation fix is correct and minimal

• frame.Width - flyoutFrame.Width is the standard right-align formula and is mathematically correct
• The change is scoped strictly to the IsRTL && !FlyoutOverlapsDetailsInPopoverMode branch — no side effects on other code paths
• 1-line change in exactly the right location

Test guard correctly updated

• Removing TEST_FAILS_ON_IOS is the right action — the comment explained the guard existed specifically because of issue Flyout Items Not Displayed in RightToLeft FlowDirection on iOS in Landscape Orientation and Hamburger Icon Positioned Incorrectly #26726, which this PR fixes

---

🟡 Suggestions

1. Trailing whitespace on [Test] attribute (minor)

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/XFIssue/Issue2818.cs, line 37

[Test]  
public async Task RootViewSizeDoesntChangeAfterBackground()

There are two trailing spaces after [Test]. Not functionally significant, but inconsistent with repo style.

Recommendation: Remove the trailing whitespace.

---

2. Pre-existing: PlatformAffected.Android in HostApp [Issue] attribute

File: src/Controls/tests/TestCases.HostApp/Issues/XFIssue/Issue2818.cs, line 4

[Issue(IssueTracker.Github, 2818, "Right-to-Left FlyoutPage in Xamarin.Forms Hamburger icon issue", PlatformAffected.Android)]

The PlatformAffected is Android, but issue #2818 (and the related #26726 being fixed here) affects iOS. This is a pre-existing annotation, but since this PR is enabling the test on iOS, updating it to PlatformAffected.iOS (or PlatformAffected.All) would be semantically correct.

Recommendation: Consider updating to PlatformAffected.iOS or PlatformAffected.All as part of this PR. Not a blocker.

---

3. Polling loop uses cached element reference (low risk — likely fine)

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/XFIssue/Issue2818.cs, lines 53–63

var newWindowSize = App.WaitForElement("RootLayout");
// ...
while (newWindowSize.GetRect().Width != windowSize.GetRect().Width && retries-- > 0)
{
    await Task.Delay(100);
}

newWindowSize is fetched once before the loop. Inside the loop, newWindowSize.GetRect() is called on the same cached element reference. In Appium/Selenium, GetRect() on a cached element typically makes a live query to the driver each time, so this should yield fresh measurements on each iteration. However, the same is true for windowSize.GetRect() — both are live queries, so the comparison should be correct.

Observation: The intent is clear and the pattern is acceptable. However, if GetRect() ever returns a stale value on a cached element, the polling would not work as intended. An alternative would be to call App.WaitForElement("RootLayout") inside the loop to get a fresh element reference each iteration.

Recommendation: Low risk as-is. Optional improvement: fetch a fresh newWindowSize inside the loop for clarity, or add a comment noting that GetRect() is a live Appium query.

---

🔴 Critical Issues

None.

---