Fixed FlowDirection property not working on Drawable control and GraphicsView

[Dhivya-SF4094]

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

The FlowDirection property is not functioning as expected when applied to Drawable controls and GraphicsView.
When FlowDirection is set to either RightToLeft or LeftToRight, there is no observable change in layout behavior.

Root Cause

ShapeViewHandler had no FlowDirection mapper, and ShapeDrawable.Draw() never applied canvas mirroring.

Description of Change

Android: Updated PlatformGraphicsView to mirror its content horizontally when the layout direction is RTL by applying a translation and scale transformation in the Draw method.
iOS: Modified PlatformGraphicsView to check EffectiveUserInterfaceLayoutDirection and apply a horizontal flip transformation when in RTL mode.
Windows: Changed PlatformGraphicsView to concatenate a scale and translation transform for RTL flow direction before drawing content.

Validated the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed:

Fixes #34402

Screenshots

Before	After
34402_BeforeChange.mov	34402_AfterChanges.mov

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

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

This PR fixes FlowDirection support for Shape-based drawables (e.g., BoxView/ShapeView) and GraphicsView by ensuring RTL flow direction results in a mirrored drawing surface across Android/iOS/Windows, and adds UI test coverage for issue #34402.

Changes:

• Mirror PlatformGraphicsView drawing output in RTL mode on Android, iOS, and Windows.
• Add FlowDirection mapping to ShapeViewHandler so shape-backed controls react to FlowDirection changes.
• Add a HostApp repro page + Appium screenshot tests (and snapshots) for issue #34402.

Reviewed changes

Copilot reviewed 7 out of 15 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Graphics/src/Graphics/Platforms/Android/PlatformGraphicsView.cs	Mirrors the Android canvas in RTL by translating + scaling before drawing.
src/Graphics/src/Graphics/Platforms/iOS/PlatformGraphicsView.cs	Mirrors the CoreGraphics context in RTL using TranslateCTM + ScaleCTM, scoped with save/restore.
src/Graphics/src/Graphics/Platforms/Windows/PlatformGraphicsView.cs	Applies a Win2D transform (scale + translation) in RTL before drawing.
src/Core/src/Handlers/ShapeView/ShapeViewHandler.cs	Adds a FlowDirection mapper to ensure shape views update and invalidate when flow direction changes.
src/Core/src/Handlers/ShapeView/ShapeViewHandler.Standard.cs	Adds the corresponding stub mapper for non-platform builds.
src/Controls/tests/TestCases.HostApp/Issues/Issue34402.cs	Adds a HostApp page to reproduce and visually validate LTR↔RTL mirroring for BoxView and GraphicsView.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34402.cs	Adds Appium tests that validate the mirroring via screenshot baselines.
src/Controls/tests/TestCases.Android.Tests/snapshots/android/GraphicsView_RTL_AfterButton.png	Adds/updates an Android screenshot baseline for the new test.

[sheiksyedm]

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

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[kubaflo]

Could you please look at the AI's summary?

[Dhivya-SF4094]

Could you please look at the AI's summary?

The gate failure on Android appears to be environment-related — one leg was blocked by an ADB0010 broken pipe error (infra issue, not a test failure), and the secondary ~2.08% GraphicsViewFlowDirectionShouldMirrorOnRTL screenshot drift is consistent with emulator rendering noise; the test passes consistently in local runs.

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Dhivya-SF4094]

Validated the AI summary concerns and confirmed that the concerns are invalid.

[kubaflo]

Code Review — PR #34557

Independent Assessment

What this changes: Three-pronged fix for FlowDirection not working on BoxView/ShapeView and GraphicsView:

1. ShapeViewHandler mapper — Adds FlowDirection mapper entry that calls UpdateFlowDirection + InvalidateShape to trigger a redraw when flow direction changes.
2. PlatformGraphicsView canvas mirroring (Android/iOS/Windows) — In each platform's Draw method, detects RTL layout direction and applies a horizontal flip transformation (Translate + Scale(-1, 1)) before drawing content.
3. Tests + snapshots — New HostApp page with BoxView and GraphicsView toggle tests, screenshot baselines for 4 platforms.

Inferred motivation: When FlowDirection is set to RTL on a BoxView or GraphicsView, the drawn content (corner radii, custom paths) should appear mirrored. The base ViewHandler.ViewMapper already maps FlowDirection → UpdateFlowDirection, but for shapes/graphics views, the native layout direction change alone isn't enough — the canvas drawing must also be mirrored.

Reconciliation with PR Narrative

Author claims: ShapeViewHandler had no FlowDirection mapper, and ShapeDrawable.Draw() never applied canvas mirroring.

Correction: The base ViewHandler.ViewMapper already maps FlowDirection (line 49 of ViewHandler.cs), and ShapeViewHandler.Mapper inherits from it. So UpdateFlowDirection was already being called. The real missing piece is the InvalidateShape call (forcing a redraw) and the canvas-level mirroring in each platform's PlatformGraphicsView.Draw().

Findings

⚠️ Warning — Duplicate FlowDirection mapper entry overrides base handler behavior

ShapeViewHandler.Mapper inherits from ViewHandler.ViewMapper, which already has [nameof(IView.FlowDirection)] = MapFlowDirection. The PR adds a second entry with the same key. In PropertyMapper, later entries override earlier ones, so the base ViewHandler.MapFlowDirection is replaced entirely.

The base MapFlowDirection has important logic:

public static void MapFlowDirection(IViewHandler handler, IView view)
{
    if (handler.IsConnectingHandler() && view.FlowDirection == FlowDirection.MatchParent)
        return;
    ((PlatformView?)handler.PlatformView)?.UpdateFlowDirection(view);
}

The IsConnectingHandler() guard prevents unnecessary work during initial connection when FlowDirection is MatchParent. The PR's MapFlowDirection doesn't have this guard, meaning it will call UpdateFlowDirection + InvalidateShape during every handler connection even when FlowDirection is MatchParent.

Suggestion: Call ViewHandler.MapFlowDirection(handler, shapeView) first (or replicate the guard), then add the InvalidateShape call:

internal static void MapFlowDirection(IShapeViewHandler handler, IShapeView shapeView)
{
    ViewHandler.MapFlowDirection(handler, shapeView);
    handler.PlatformView?.InvalidateShape(shapeView);
}

⚠️ Warning — Mixed indentation in MapFlowDirection body

ShapeViewHandler.cs lines 75-78 use mixed tabs and spaces:

		internal static void MapFlowDirection(IShapeViewHandler handler, IShapeView shapeView)
  		{                          // <-- space-indented
			handler.PlatformView?.UpdateFlowDirection(shapeView);
   			handler.PlatformView?.InvalidateShape(shapeView);  // <-- space-indented
  		}                          // <-- space-indented

The file uses tabs elsewhere. This will likely be caught by dotnet format, but worth fixing before merge.

⚠️ Warning — Windows canvas transform is not reset between draws

In PlatformGraphicsView.cs (Windows), the RTL transform is applied via _canvas.ConcatenateTransform(...) inside the try block, and _canvas.ResetState() is called in finally. If ResetState() clears concatenated transforms (which it should from AbstractCanvas.ResetState), this is correct. However, ConcatenateTransform is applied before _drawable.Draw but after _canvas.Session is set — the transform accumulates with whatever state Session already has. This should be fine since the session is freshly set each draw, but it differs from Android/iOS which use explicit save/restore patterns.

⚠️ Warning — macOS BoxView_RTL_AfterButton snapshot missing

The diff shows new snapshots for mac/BoxView_LTR_Initial.png and mac/GraphicsView_*.png, but no mac/BoxView_RTL_AfterButton.png. The test BoxViewFlowDirectionShouldMirrorOnRTL takes a screenshot named BoxView_RTL_AfterButton — if no macOS baseline exists, the test will fail on macCatalyst.

✅ Correct — Canvas mirroring approach is standard and consistent across platforms

The Translate(width, 0) + Scale(-1, 1) pattern is the standard way to mirror a canvas horizontally. Applied consistently:

• Android: androidCanvas.Translate(Width, 0); androidCanvas.Scale(-1, 1); with Save()/RestoreToCount()
• iOS: coreGraphics.TranslateCTM(Width, 0); coreGraphics.ScaleCTM(-1, 1); with SaveState()/RestoreState()
• Windows: Matrix3x2.CreateScale(-1, 1) * Matrix3x2.CreateTranslation(width, 0) with ResetState()

✅ Correct — Test page explicitly sets FlowDirection = LeftToRight

Both BoxView and GraphicsView start with FlowDirection = FlowDirection.LeftToRight, ensuring deterministic initial screenshots regardless of device locale. This was a previous reviewer concern that was addressed.

✅ Correct — MapFlowDirection marked internal with TODO

The // TODO: make it public in .net 11 comment acknowledges that adding a public static mapper method is an API addition that belongs on the net11.0 branch. Marking it internal for main is the correct approach for a bug fix branch.

✅ Correct — Standard.cs stub added

ShapeViewHandler.Standard.cs gets the matching internal static void MapFlowDirection stub, preventing compilation failures on unsupported platforms.

CI Status

• maui-pr: macOS Release build failed — needs investigation
• Most other stages pass (builds, Helix, integration tests)
• The macOS build failure may be related to the mixed indentation or a pre-existing issue

Devil's Advocate

1. Could the canvas mirroring break existing drawing code? Only for views that explicitly set FlowDirection = RTL. The default is MatchParent which resolves to LTR in most locales. For RTL locales, this is the desired behavior — graphics should mirror. Users who draw RTL-aware content themselves can set FlowDirection = LeftToRight explicitly to opt out.

2. Does mirroring affect touch/gesture coordinates? The mirroring is only in the draw path, not in the touch handling. Touch coordinates use the native view's coordinate system, which may or may not account for RTL. However, this is pre-existing behavior — this PR doesn't change touch handling.

3. Could InvalidateShape cause performance issues if called frequently? InvalidateShape triggers a redraw. FlowDirection typically changes at most once (app startup or language switch), so this is not a hot path.

Verdict: LGTM with minor notes

Confidence: high

Summary: Correct fix for a genuine gap — canvas content was not being mirrored for RTL layout direction on any platform. The mirroring approach is standard and consistently applied across Android, iOS, and Windows. The ShapeViewHandler mapper override should ideally delegate to the base MapFlowDirection before adding InvalidateShape to preserve the IsConnectingHandler guard. Mixed indentation and a potentially missing macOS snapshot are minor cleanup items. The internal visibility with .NET 11 TODO is the right approach for the main branch.