[Shapes] Line: Fix asymmetric Stretch.None path translation when right/bottom edge overflows

[NirmalKumarYuvaraj]

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:

Two bugs in the Stretch.None branch:

1. Only left/top edges were checked — right/bottom overflow was ignored
2. Translation formula pathBounds.X + viewBounds.Left - pathBounds.Left simplifies to just viewBounds.Left (a fixed absolute, not a relative offset), causing both mirror-image lines to receive the same
   translateX

What NOT to Do:
- ❌ Don't use pathBounds.X + viewBounds.Left - pathBounds.Left — simplifies to an absolute position
- ❌ Don't check only left/top — reversed-coordinate paths overflow right/bottom
- ❌ Don't center paths for Stretch.None — breaks semantics for paths already within bounds

Description of Change

This pull request addresses an issue where line coordinates were not computed correctly in certain scenarios, specifically impacting the symmetry of rendered lines. The changes include a fix to the path transformation logic for shapes with Stretch.None, and the addition of both a manual test case and an automated UI test to verify the fix.

Bug fix: Path transformation for Stretch.None

• Improved the logic in TransformPathForBounds in Shape.cs to correctly translate paths within view bounds for shapes with Stretch.None, ensuring that lines are properly aligned and symmetric when rendered.

Testing and validation:

• Added a new manual test page Issue11404 in the test host app to visually verify that two thick red lines form a symmetric "V" shape and programmatically check the symmetry of their computed bounds.
• Introduced an automated UI test for Issue11404 to assert that the rendered lines are symmetric by checking the computed result label, ensuring the fix is validated across platforms.

Issues Fixed

Fixes #11404
Fixes #26961

Output

Before	After

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

Or

• Run remotely in PowerShell:

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

[sheiksyedm]

/azp run maui-pr-uitests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR fixes Shape path translation for Stretch.None so that paths that overflow on the right/bottom edges are translated correctly (and symmetric line rendering isn’t broken by an absolute translation). It also adds a HostApp repro page plus an Appium UI test to validate the symmetry scenario.

Changes:

• Fix Shape.TransformPathForBounds (Stretch.None) to translate paths based on relative overflow on all four edges (left/right/top/bottom).
• Add HostApp issue page Issue11404 that renders symmetric lines and computes a pass/fail result via PathForBounds.
• Add Appium UI test Issue11404 asserting the computed result is “Pass”.

Reviewed changes

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

File	Description
src/Controls/src/Core/Shapes/Shape.cs	Corrects Stretch.None translation logic to handle right/bottom overflow and avoid absolute translation bugs.
src/Controls/tests/TestCases.HostApp/Issues/Issue11404.cs	Adds a repro page that draws symmetric lines and sets a result label based on computed path bounds.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue11404.cs	Adds an Appium test that navigates to the repro page and asserts the symmetry check passes.

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 20aecf7 · updated 11404 Platforms

---

🔍 Pre-Flight — Context & Validation

---

Issue: #11404 - Line coordinates not computed correctly
Related Issue: #26961 - Lines not drawing correctly (Windows)
PR: #34385 - [Shapes] Line: Fix asymmetric Stretch.None path translation when right/bottom edge overflows
Platforms Affected: Android, iOS (fix in shared code also addresses Windows per #26961)
Files Changed: 1 implementation, 2 test

Key Findings

• Issue Line coordinates not computed correctly #11404 reports asymmetric rendering for thick mirrored Line shapes on iOS and Android — the right-hand thick red line overflows to the right instead of rendering symmetrically.
• Root cause: Two bugs in Shape.TransformPathForBounds for Stretch.None:
  1. Only left/top edge overflow was checked — right/bottom overflow ignored
  2. The translation formula pathBounds.X + viewBounds.Left - pathBounds.Left simplifies to viewBounds.Left (an absolute constant, not a relative offset), causing mirror-image lines to receive the same translateX
• The fix uses correct relative offsets (viewBounds.Left - pathBounds.Left) and adds else if branches for right/bottom overflow.
• Prior agent review (from MauiBot) flagged two concerns: (1) test race on WaitForElement("SymmetryResult") — element exists immediately with "Checking...", and (2) PlatformAffected.iOS | PlatformAffected.Android should be .All. The platform concern was addressed; the race concern was dismissed by the author as "Invalid suggestion".
• The test race is still present in the current PR diff: App.WaitForElement("SymmetryResult") only confirms element existence (label starts with "Checking..."), then immediately calls App.FindElement("SymmetryResult").GetText(). The Gate PASSED on Android (March 28), suggesting the race does not manifest consistently in practice.
• Latest Gate result: ✅ PASSED on Android.

Edge Cases / Discussion Notes

• The else if structure means only one edge is corrected per axis — if both left AND right overflow simultaneously (path wider than view), right edge is not corrected. However, this edge case cannot apply to the bug scenario (mirrored lines within view bounds).
• WaitForElement only waits for element visibility, not for text to be updated from "Checking...". This is a valid but low-severity flakiness risk.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34385	Fix Stretch.None translation with correct relative offsets + add right/bottom overflow checks; add Issue11404 HostApp page and Appium UI test	✅ PASSED (Gate - Android)	src/Controls/src/Core/Shapes/Shape.cs, src/Controls/tests/TestCases.HostApp/Issues/Issue11404.cs, src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue11404.cs	Original PR

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Math.Max/Math.Min clamping — clampedLeft = Math.Max(viewBounds.Left, Math.Min(pathBounds.Left, viewBounds.Right - pathBounds.Width)), translateX = clampedLeft - pathBounds.Left	✅ PASS	1 file	Compact; mathematically equivalent to PR fix
2	try-fix (claude-sonnet-4.6)	Signed per-edge overflow — Math.Max(0, edge_overflow) for 4 edges, ternary selection (left/top priority)	✅ PASS	1 file	Clean separation of overflow magnitude and direction
3	try-fix (gpt-5.3-codex)	Signed edge-distance formula — compute both left/right deltas, pick the one with appropriate sign	✅ PASS	1 file	Minimal formula correction; structurally similar to PR
4	try-fix (gpt-5.4)	View-local coordinate normalization — shift pathBounds into view-local coords, clamp, compose with view origin offset	✅ PASS	1 file	Most complex; adds indirection not needed for this fix
PR	PR #34385	Explicit if/else if branches for each of 4 edges with relative offsets	✅ PASSED (Gate)	3 files	Original PR — includes test files

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	No	All approaches cover the solution space
claude-sonnet-4.6	2	No	NO NEW IDEAS
gpt-5.3-codex	2	Proposed	"1D constraint interval per axis, pick value closest to 0" — mathematically equivalent to Attempt 1 (clamping), not explored
gpt-5.4	2	No	NO NEW IDEAS

Exhausted: Yes
Selected Fix: PR's fix — Reason: The explicit if/else if branch structure is the most readable and matches the codebase's existing conditional style. All 4 alternatives are mathematically equivalent; the PR's approach is the clearest for future maintainers and includes the test files needed for coverage.

---

📋 Report — Final Recommendation

---

✅ Final Recommendation: APPROVE

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Issues #11404 and #26961; fix in shared Shape code; test race noted
Gate	✅ PASSED	Android — tests FAIL without fix, PASS with fix
Try-Fix	✅ COMPLETE	4 attempts, all 4 passing; PR's fix selected
Report	✅ COMPLETE

Summary

PR #34385 fixes a long-standing bug in Shape.TransformPathForBounds for Stretch.None where thick mirrored Line shapes rendered asymmetrically on Android and iOS. The fix is correct, well-scoped, and the Gate confirmed it works on Android. Four independent alternative fixes were explored — all passed, confirming the PR's approach is sound. The PR's if/else if branch structure was selected as the best fix for clarity and codebase consistency.

Root Cause

Two bugs in Shape.TransformPathForBounds (Stretch.None branch):

1. Wrong formula: pathBounds.X + viewBounds.Left - pathBounds.Left simplified to the constant viewBounds.Left, so every path received the same absolute translation regardless of position — causing mirror-image lines to both shift to the same X coordinate.
2. Missing overflow check: Only left/top edge overflow was handled; right/bottom overflow (which occurs when line coordinates are reversed, e.g., X1=200, X2=100) was ignored.

Fix Quality

Implementation (Shape.cs): The fix is correct and minimal. It replaces the broken formula with proper relative offsets and adds else if branches for right/bottom overflow. The else if structure (not if) correctly handles the one-edge-per-axis constraint — a path can only overflow one side per axis at a time.

Test coverage: Good. The HostApp page uses SizeChanged + PathForBounds computation to check path symmetry mathematically (not just visually), providing reliable validation without screenshot flakiness.

One remaining concern (low severity): The Appium test calls App.WaitForElement("SymmetryResult") which returns as soon as the label element exists (initial text: "Checking..."), then immediately reads the text. The Gate passed on Android, so in practice the SizeChanged event fires before Appium reads the label. However, this is a latent flakiness risk. A more robust pattern would be to poll until the text is not "Checking...". The prior review comment (Copilot reviewer) suggested this fix; the author dismissed it. Given Gate PASSED, this is not blocking, but worth noting for long-term test health.

Whitespace fix: The PR also fixes a mixed-indentation issue in MeasureOverride (spaces → tabs), which is correct.

Selected Fix: PR's fix — most readable, matches codebase style, has complete test coverage.

---

[kubaflo]

Could you please review the AI's summary?

[NirmalKumarYuvaraj]

@kubaflo , Addressed the AI review summary concern. No major code changes in the review summary. The implemented fix is the best approach.

[MauiBot]

🚦 Gate — Test Verification

📊 Expand Full Gate — 20aecf7 · updated 11404 Platforms

---

Gate Result: ✅ PASSED

Platform: ANDROID

Tests Detected

#	Type	Test Name	Filter
1	UITest	Issue11404	Issue11404

Verification

Step	Expected	Actual	Result
Without fix	FAIL	FAIL	✅
With fix	PASS	PASS	✅

Fix Files Reverted

• eng/pipelines/ci-copilot.yml
• src/Controls/src/Core/Shapes/Shape.cs

---

Base Branch: main | Merge Base: 720a9d4

---