[Windows] Fix Shell title bar overlap with window controls in RTL mode

[Shalini-Ashokan]

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 Details

When Shell.FlowDirection is set to RightToLeft on Windows, the Shell title and hamburger menu overlap with native window control buttons (minimize, maximize, close) because the content mirrors to RTL while title bar buttons remain on the right side.

Root Cause

Windows title bar buttons stay fixed on the right side by default, but Shell UI elements (title, hamburger menu) mirror to the right in RTL mode, causing visual overlap and making window controls unusable.

Description of Change

Applied WS_EX_LAYOUTRTL extended window style flag to mirror the entire window including title bar buttons to the left side, and set WindowRootView.FlowDirection to properly handle WinUI content layout, ensuring all elements move together consistently in RTL mode without overlap.

Validated the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #32476

Output ScreenShot

Before	After

[dotnet-policy-service]

Hey there @@Shalini-Ashokan! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

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

Or

• Run remotely in PowerShell:

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

[Shalini-Ashokan]

🤖 AI Summary

📊 Expand Full Review — c5c00f1 · committed the images

Concern 1: PlatformMethods is internal to the Microsoft.Maui.Essentials assembly (Microsoft.Maui.ApplicationModel namespace) and is not accessible from the handler layer. Using raw P/Invokes is the only viable option here.

Concern 2: This concern is not valid. handler.MauiContext?.Services?.GetService() resolves from the handler's own scoped MauiContext, which is already bound to the current window — it cannot return an arbitrary window.

Concern 3: No other handler in the MAUI codebase uses a nested NativeMethods class, so this is not an established pattern to follow. The current approach is consistent with the rest of the codebase.

Concern 4 : Using retryTimeout caused errors during testing, so it was intentionally avoided.

concern 5 & 6 : I resolved the concerns.

[Copilot]

Pull request overview

Fixes a Windows Shell RTL layout issue where the Shell title/hamburger can overlap native window caption buttons by mirroring the window’s non-client area when Shell.FlowDirection is RightToLeft, and adds UI test coverage/snapshots for the scenario.

Changes:

• Update Windows ShellHandler flow-direction mapping to apply WS_EX_LAYOUTRTL and adjust the root view flow direction.
• Add new HostApp repro (Issue32476) and a corresponding UI test with updated baseline screenshots for Windows and Mac.
• Add new snapshot baselines for ShellRTLFlowDirectionShouldNotCauseOverlap on WinUI and Mac.

Reviewed changes

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

Show a summary per file

File	Description
src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs	Applies a Win32 extended window style during RTL to mirror the title bar/caption buttons and sets WindowRootView.FlowDirection.
src/Controls/tests/TestCases.HostApp/Issues/Issue32476.cs	Adds a Shell-based repro page with a button intended to switch FlowDirection to RTL.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32476.cs	Adds an Appium/NUnit UI test validating no overlap (via screenshot).
src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/ShellRTLFlowDirectionShouldNotCauseOverlap.png	Adds/updates the Windows screenshot baseline for the new test.
src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/ShellRTLFlowDirectionShouldNotCauseOverlap.png	Adds/updates the Mac screenshot baseline for the new test.

[kubaflo]

/review -b feature/refactor-copilot-yml -p windows

[kubaflo]

/review -b feature/refactor-copilot-yml

[MauiBot]

🤖 Automated review — alternative fix proposed

The expert-reviewer evaluation compared the PR fix against #1 automatically generated candidates and selected try-fix-1 as the strongest fix.

Why: try-fix-1 won because it passed the regression test and centralizes Windows native RTL mirroring in WindowHandler, avoiding the raw Shell.FlowDirection/MatchParent bug found by expert review. The raw PR passed the gate but has an inherited RTL correctness issue, and pr-plus-reviewer improves it without matching try-fix-1's cleaner ownership model or empirical STEP 6a pass.

Please consider applying the candidate diff below (or use it as guidance). Once you push an update, this workflow will re-trigger and re-evaluate.

Candidate diff (`try-fix-1`)

diff --git a/src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs b/src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs
index 22b3572a6a28..111111111111 100644
--- a/src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs
+++ b/src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs
@@ -173,6 +173,8 @@ public static void MapFlyout(ShellHandler handler, IFlyoutView flyoutView)
 internal static void MapFlowDirection(ShellHandler handler, Shell view)
 {
 handler.PlatformView.UpdateFlowDirection(view);
+// Delegate native-window RTL mirroring to WindowHandler, which owns WS_EX_LAYOUTRTL.
+view.Window?.Handler?.UpdateValue(nameof(IWindow.FlowDirection));
 }
 
 public static void MapIsPresented(ShellHandler handler, IFlyoutView flyoutView)
diff --git a/src/Core/src/Handlers/Window/WindowHandler.Windows.cs b/src/Core/src/Handlers/Window/WindowHandler.Windows.cs
index 19a938f305b2..222222222222 100644
--- a/src/Core/src/Handlers/Window/WindowHandler.Windows.cs
+++ b/src/Core/src/Handlers/Window/WindowHandler.Windows.cs
@@ -144,6 +144,12 @@ public static void MapFlowDirection(IWindowHandler handler, IWindow view)
 
 if (updated_style != extended_style)
 PlatformMethods.SetWindowLongPtr(WindowHandle, PlatformMethods.WindowLongFlags.GWL_EXSTYLE, updated_style);
+
+var windowRootView = handler.MauiContext?.GetNavigationRootManager()?.RootView as Microsoft.Maui.Platform.WindowRootView;
+if (windowRootView != null)
+windowRootView.FlowDirection = view.FlowDirection == FlowDirection.RightToLeft
+? UI.Xaml.FlowDirection.RightToLeft
+: UI.Xaml.FlowDirection.LeftToRight;
 }
 
 public static void MapRequestDisplayDensity(IWindowHandler handler, IWindow window, object? args)

[MauiBot]

Expert Review — 2 findings

See inline comments for details.

[MauiBot]

[major] Logic and Correctness — This derives the native window RTL state from Shell.FlowDirection == RightToLeft, which treats MatchParent as LTR and can clear WS_EX_LAYOUTRTL even when the Shell is effectively RTL through inheritance/window flow direction. Concrete scenario: an app sets the Window/root flow direction to RTL while Shell remains at its default MatchParent; this mapper will remove the window RTL style and put title-bar buttons back on the right, reintroducing overlap. Use the effective flow direction or route through the existing Window flow-direction mapping so Shell and Window state do not fight.

[MauiBot]

[moderate] Regression Prevention — The fixed Task.Delay(500).Wait() makes this screenshot test timing-dependent. On slower Windows/MacCatalyst CI runs the title-bar/non-client update can still be in flight after 500 ms, causing a flaky snapshot even when the product fix is correct. Prefer VerifyScreenshot(retryTimeout: ...) so the screenshot assertion retries until the layout stabilizes.

[MauiBot]

🤖 AI Summary

👋 @Shalini-Ashokan — new AI review results are available. Please review the latest session below.

📊 Review Session — efdad8c · committed the changes · 2026-05-24 17:03 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ✅ PASSED

Platform: WINDOWS · Base: main · Merge base: b0ea772f

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue32476 Issue32476	✅ FAIL — 470s	✅ PASS — 443s

🔴 Without fix — 🖥️ Issue32476: FAIL ✅ · 470s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Essentials.dll
  Graphics.Win2D -> D:\a\1\s\artifacts\bin\Graphics.Win2D\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.Win2D.WinUI.Desktop.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.dll
  Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Controls.Foldable -> D:\a\1\s\artifacts\bin\Controls.Foldable\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Foldable.dll
  Maps -> D:\a\1\s\artifacts\bin\Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Maps.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Microsoft.AspNetCore.Components.WebView.Maui -> D:\a\1\s\artifacts\bin\Microsoft.AspNetCore.Components.WebView.Maui\Debug\net10.0-windows10.0.19041.0\Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> D:\a\1\s\artifacts\bin\Controls.Xaml\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Xaml.dll
  Controls.Maps -> D:\a\1\s\artifacts\bin\Controls.Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Maps.dll
  Controls.TestCases.HostApp -> D:\a\1\s\artifacts\bin\Controls.TestCases.HostApp\Debug\net10.0-windows10.0.19041.0\win-x64\Controls.TestCases.HostApp.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:05:41.30
  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0\Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0\Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0\Microsoft.Maui.dll
  Controls.CustomAttributes -> D:\a\1\s\artifacts\bin\Controls.CustomAttributes\Debug\net10.0\Controls.CustomAttributes.dll
  Controls.Core.Design -> D:\a\1\s\artifacts\bin\Controls.Core.Design\Debug\net472\Microsoft.Maui.Controls.DesignTools.dll
  Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0\Microsoft.Maui.Controls.dll
  UITest.Core -> D:\a\1\s\artifacts\bin\UITest.Core\Debug\net10.0\UITest.Core.dll
  UITest.NUnit -> D:\a\1\s\artifacts\bin\UITest.NUnit\Debug\net10.0\UITest.NUnit.dll
  VisualTestUtils -> D:\a\1\s\artifacts\bin\VisualTestUtils\Debug\netstandard2.0\VisualTestUtils.dll
  VisualTestUtils.MagickNet -> D:\a\1\s\artifacts\bin\VisualTestUtils.MagickNet\Debug\netstandard2.0\VisualTestUtils.MagickNet.dll
  UITest.Appium -> D:\a\1\s\artifacts\bin\UITest.Appium\Debug\net10.0\UITest.Appium.dll
  UITest.Analyzers -> D:\a\1\s\artifacts\bin\UITest.Analyzers\Debug\netstandard2.0\UITest.Analyzers.dll
  Controls.TestCases.WinUI.Tests -> D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
Test run for D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 5/24/2026 3:27:02 PM FixtureSetup for Issue32476(Windows)
>>>>> 5/24/2026 3:27:13 PM ShellRTLFlowDirectionShouldNotCauseOverlap Start
>>>>> 5/24/2026 3:27:17 PM ShellRTLFlowDirectionShouldNotCauseOverlap Stop
>>>>> 5/24/2026 3:27:18 PM Log types: 
  Failed ShellRTLFlowDirectionShouldNotCauseOverlap [5 s]
  Error Message:
   VisualTestUtils.VisualTestFailedException : 
Snapshot different than baseline: ShellRTLFlowDirectionShouldNotCauseOverlap.png (0.72% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.

More info: https://aka.ms/visual-test-workflow

  Stack Trace:
     at VisualTestUtils.VisualRegressionTester.Fail(String message) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 162
   at VisualTestUtils.VisualRegressionTester.VerifyMatchesSnapshot(String name, ImageSnapshot actualImage, String environmentName, ITestContext testContext) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 123
   at Microsoft.Maui.TestCases.Tests.UITest.<VerifyScreenshot>g__Verify|13_0(String name, <>c__DisplayClass13_0&) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 477
   at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance, Boolean includeTitleBar) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 309
   at Microsoft.Maui.TestCases.Tests.Issues.Issue32476.ShellRTLFlowDirectionShouldNotCauseOverlap() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32476.cs:line 23
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

NUnit Adapter 4.5.0.0: Test execution complete
[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.11]   Discovering: Controls.TestCases.WinUI.Tests
[xUnit.net 00:00:00.31]   Discovered:  Controls.TestCases.WinUI.Tests
Results File: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue32476.trx

Total tests: 1
     Failed: 1
Test Run Failed.
 Total time: 29.8895 Seconds
>>> TRX_RESULT_FILE: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue32476.trx

🟢 With fix — 🖥️ Issue32476: PASS ✅ · 443s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Graphics.Win2D -> D:\a\1\s\artifacts\bin\Graphics.Win2D\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.Win2D.WinUI.Desktop.dll
  Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.dll
  Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Maps -> D:\a\1\s\artifacts\bin\Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Maps.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Controls.Maps -> D:\a\1\s\artifacts\bin\Controls.Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Maps.dll
  Controls.Xaml -> D:\a\1\s\artifacts\bin\Controls.Xaml\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Xaml.dll
  Controls.Foldable -> D:\a\1\s\artifacts\bin\Controls.Foldable\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Foldable.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> D:\a\1\s\artifacts\bin\Microsoft.AspNetCore.Components.WebView.Maui\Debug\net10.0-windows10.0.19041.0\Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.TestCases.HostApp -> D:\a\1\s\artifacts\bin\Controls.TestCases.HostApp\Debug\net10.0-windows10.0.19041.0\win-x64\Controls.TestCases.HostApp.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:05:28.17
  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0\Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0\Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0\Microsoft.Maui.dll
  Controls.CustomAttributes -> D:\a\1\s\artifacts\bin\Controls.CustomAttributes\Debug\net10.0\Controls.CustomAttributes.dll
  Controls.Core.Design -> D:\a\1\s\artifacts\bin\Controls.Core.Design\Debug\net472\Microsoft.Maui.Controls.DesignTools.dll
  Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14182750
  Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0\Microsoft.Maui.Controls.dll
  VisualTestUtils -> D:\a\1\s\artifacts\bin\VisualTestUtils\Debug\netstandard2.0\VisualTestUtils.dll
  UITest.Core -> D:\a\1\s\artifacts\bin\UITest.Core\Debug\net10.0\UITest.Core.dll
  UITest.NUnit -> D:\a\1\s\artifacts\bin\UITest.NUnit\Debug\net10.0\UITest.NUnit.dll
  UITest.Appium -> D:\a\1\s\artifacts\bin\UITest.Appium\Debug\net10.0\UITest.Appium.dll
  VisualTestUtils.MagickNet -> D:\a\1\s\artifacts\bin\VisualTestUtils.MagickNet\Debug\netstandard2.0\VisualTestUtils.MagickNet.dll
  UITest.Analyzers -> D:\a\1\s\artifacts\bin\UITest.Analyzers\Debug\netstandard2.0\UITest.Analyzers.dll
  Controls.TestCases.WinUI.Tests -> D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
Test run for D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 5/24/2026 3:34:28 PM FixtureSetup for Issue32476(Windows)
>>>>> 5/24/2026 3:34:38 PM ShellRTLFlowDirectionShouldNotCauseOverlap Start
>>>>> 5/24/2026 3:34:42 PM ShellRTLFlowDirectionShouldNotCauseOverlap Stop
  Passed ShellRTLFlowDirectionShouldNotCauseOverlap [3 s]
NUnit Adapter 4.5.0.0: Test execution complete
[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.12]   Discovering: Controls.TestCases.WinUI.Tests
[xUnit.net 00:00:00.31]   Discovered:  Controls.TestCases.WinUI.Tests
Results File: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue32476.trx

Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 27.5762 Seconds
>>> TRX_RESULT_FILE: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue32476.trx

📁 Fix files reverted (2 files)

• eng/pipelines/ci-copilot.yml
• src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs

---

🧪 UI Tests — Shell

Detected UI test categories: Shell

✅ Deep UI tests — 267 passed, 0 failed across 1 category on platform-pool agent (replaces in-process counts above).

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
Shell	267/267 ✓	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

🔍 Regression Cross-Reference

🔍 Regression Cross-Reference

🟢 No regression risks detected. No labeled bug-fix PRs in the last 6 months touched the modified files.

---

🔍 Pre-Flight — Context & Validation

Issue: #32476 - [Windows] Binding RTL FlowDirection in Shell causes Flyout MenuIcon and native window controls to overlap
PR: #33109 - [Windows] Fix Shell title bar overlap with window controls in RTL mode
Platforms Affected: Windows
Files Changed: 1 implementation, 4 test/snapshot

Key Findings

• The bug occurs when Windows Shell content is mirrored to RTL but native caption buttons remain on the right, causing Shell title/flyout icon overlap with minimize/maximize/close controls.
• PR fix toggles WS_EX_LAYOUTRTL from ShellHandler.Windows.MapFlowDirection and sets WindowRootView.FlowDirection; the gate result supplied to this run says the regression test fails without the fix and passes with the PR fix.
• Prior review discussion noted raw P/Invokes are used because PlatformMethods is internal to Essentials, and the author reported avoiding VerifyScreenshot(retryTimeout:) due to errors.
• Independent code review found the Shell mapper treats FlowDirection.MatchParent as LTR, which can clear inherited RTL window state.

Code Review Summary

Verdict: NEEDS_CHANGES
Confidence: high
Errors: 1 | Warnings: 1 | Suggestions: 0

Key code review findings:

• Error: src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs:184-193 computes isRtl from view.FlowDirection == FlowDirection.RightToLeft, so MatchParent can clear an inherited RTL native window style and force WindowRootView.FlowDirection to LTR.
• Warning: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32476.cs:21-23 uses a fixed Task.Delay(500).Wait() before VerifyScreenshot; UI test guidance prefers built-in screenshot retry/stability mechanisms.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33109	Toggle WS_EX_LAYOUTRTL in ShellHandler.Windows.MapFlowDirection and set WindowRootView.FlowDirection based on explicit Shell FlowDirection.	PASSED (Gate)	ShellHandler.Windows.cs, UI test/snapshots	Original PR; gate result provided by caller.

---

🔬 Code Review — Deep Analysis

Code Review PR #33109

Independent Assessment

What this changes: On Windows Shell, MapFlowDirection now mirrors the native window by toggling WS_EX_LAYOUTRTL and forces WindowRootView.FlowDirection to match whether Shell.FlowDirection is exactly RightToLeft. It also adds a Shell issue page plus Windows/MacCatalyst screenshot UI coverage.
Inferred motivation: The change is intended to keep Shell chrome/hamburger/title and native caption buttons from occupying the same side when Shell is switched to RTL dynamically.

Reconciliation with PR Narrative

Author claims: The PR fixes #32476 by applying WS_EX_LAYOUTRTL so title-bar buttons mirror with Shell RTL content, and by setting root view flow direction; screenshots/tests validate no overlap.
Agreement/disagreement: The code matches the stated goal for an explicitly RTL Shell. However, it ignores MAUI's FlowDirection.MatchParent inheritance semantics and can undo a window-level RTL setting. Existing review comments about raw P/Invoke/SetWindowPos were already discussed; I am not repeating those as blockers. CI is not green: the maui-pr check is failed and Helix unit-test checks were cancelled, so this PR should not be considered ready until CI is rerun/understood.

Findings

Error MatchParent Shell flow direction clears inherited RTL window state

src/Controls/src/Core/Handlers/Shell/ShellHandler.Windows.cs:184-193 computes isRtl from view.FlowDirection == FlowDirection.RightToLeft and treats every other value as LTR. FlowDirection.MatchParent is the default and is supposed to inherit the parent/window effective direction; ViewHandler.MapFlowDirection even skips default MatchParent mapping during connect on non-iOS platforms. With a window/root configured RTL and a default Shell, this mapper will clear WS_EX_LAYOUTRTL and force WindowRootView.FlowDirection to LeftToRight, breaking inherited RTL and reintroducing title-bar/content mismatch. Please use the effective flow direction (for example via the Shell's effective flow controller) or handle MatchParent without forcing LTR/clearing the style.

Warning Screenshot test uses a fixed delay before verification

src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32476.cs:21-23 waits with Task.Delay(500).Wait() immediately before VerifyScreenshot. The UI test guidance explicitly says VerifyScreenshot() already has retry/stability logic and fixed sleeps should be replaced with retryTimeout/proper waits to avoid flaky timing. If retryTimeout failed in this scenario, the reason should be captured in the test or helper rather than relying on an arbitrary sleep.

Devil's Advocate

The existing WindowHandler.Windows.MapFlowDirection also treats non-RTL as clearing WS_EX_LAYOUTRTL, so this PR follows one existing pattern. The difference is that Window itself owns the native window direction, while this Shell mapper runs from a child/root content handler and can override inherited window state for the default MatchParent Shell. The fixed sleep may be pragmatic if screenshot infrastructure has a bug with includeTitleBar, but it conflicts with current repository UI-test guidance and should at least be justified or addressed.

Verdict: NEEDS_CHANGES

Confidence: high
Summary: The explicit RTL scenario is plausible, but the mapper regresses inherited/default MatchParent flow-direction behavior by forcing the whole native window back to LTR. CI is also currently failing/cancelled, so this is not ready to merge until the flow-direction inheritance issue and CI status are addressed.

---

🔧 Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix-1	Delegate native-window RTL mirroring to the existing Window handler: Shell requests IWindow.FlowDirection remapping, and WindowHandler.Windows.MapFlowDirection owns both WS_EX_LAYOUTRTL and WindowRootView.FlowDirection.	PASS	2 files	Better than PR: removes duplicated Shell P/Invoke/native-window ownership and uses Window's existing effective flow-direction resolution, avoiding the MatchParent inheritance bug found by code review.
PR	PR #33109	ShellHandler directly toggles WS_EX_LAYOUTRTL and sets WindowRootView.FlowDirection from explicit Shell FlowDirection.	PASSED (Gate)	5 files	Original PR; gate result supplied by caller.

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	1	Yes	Window-level ownership of native RTL mirroring; implemented and passed.

Exhausted: No - stopped because Candidate #1 passed all executed tests and is demonstrably better than the PR fix.
Selected Fix: Candidate #1 - centralizes native window flow-direction handling in WindowHandler, removes Shell-level P/Invoke duplication, and addresses the MatchParent inherited RTL failure mode.

---

📋 Report — Final Recommendation

Comparative Fix Report — PR #33109

Candidates compared

Rank	Candidate	Regression result	Assessment
1	try-fix-1	PASS	Best candidate. It delegates Shell flow-direction changes to the existing Window handler and enhances WindowHandler.Windows.MapFlowDirection to update both WS_EX_LAYOUTRTL and WindowRootView.FlowDirection. This centralizes native window RTL ownership and uses IWindow.FlowDirection, whose getter already resolves explicit RTL from the Shell page.
2	pr-plus-reviewer	Not executed after sandbox patch	Better than raw PR because it applies the expert findings: effective flow-direction handling and screenshot retry instead of fixed delay. It remains architecturally weaker than try-fix-1 because Shell still duplicates low-level native window style ownership.
3	pr	PASSED gate	The submitted PR fixes the direct regression but has a concrete inherited-RTL gap: FlowDirection.MatchParent can be effectively RTL and would still clear native RTL mirroring. It also adds a timing-dependent screenshot delay.

Only one STEP 6a try-fix candidate was present in the provided logs: try-fix-1.

Winning candidate

Winner: try-fix-1

try-fix-1 is the only alternative candidate with an executed PASS result and it also addresses the expert review's highest-severity concern by avoiding Shell's raw FlowDirection decision entirely. It is architecturally preferable because Windows native window mirroring remains in WindowHandler, the handler that already owned WS_EX_LAYOUTRTL, while Shell merely requests that the Window flow-direction mapper re-evaluate.

Why not the PR fix

The raw PR passed the supplied gate, so it is a functional improvement for the explicit RTL scenario. However, the expert review identified a MAUI flow-direction correctness issue on an added line: inherited RTL through MatchParent is a supported scenario and would be mishandled by the PR's raw comparison.

Why not pr-plus-reviewer

pr-plus-reviewer is a valid improvement over the submitted PR, but it keeps duplicated P/Invoke/native-window manipulation inside ShellHandler. try-fix-1 reaches the same user-visible outcome through the existing Window handler abstraction and has empirical regression-test evidence from STEP 6a, so it is the stronger candidate.

---