[Windows, Android] Fix Border Color and Border Width Not applying for Radio Button

[HarishwaranVijayakumar]

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

• RadioButton BorderColor and BorderWidth are not updated correctly on Android and Windows when changed dynamically.

Root Cause of the issue

• RadioButton inherits border properties from BorderElement which defines BorderColorProperty (PropertyName = "BorderColor") and BorderWidthProperty (PropertyName = "BorderWidth")
• The RadioButtonHandler mapper registers keys as nameof(IRadioButton.StrokeColor) = "StrokeColor" and nameof(IRadioButton.StrokeThickness) = "StrokeThickness"
• At runtime, when a property changes: Element.OnPropertyChanged("BorderColor") → Handler.UpdateValue("BorderColor") → mapper lookup for "BorderColor" → NOT FOUND → no platform update
• At initial load, ElementHandler.SetVirtualView() calls _mapper.UpdateProperties() which iterates ALL registered keys by their mapper names, so initial values work correctly
• iOS is unaffected because it uses a ControlTemplate with data bindings that bypass the handler mapper entirely

Description of Change

Platform-specific property update fix:

• Added an override for OnPropertyChanged in RadioButton (Android and Windows) to update the handler when BorderColor or BorderWidth changes, ensuring the UI reflects these property updates at runtime.
• Registered the new override in the public API files for both Android and Windows platforms. [1] [2]

Testing and validation:

• Added a sample page (Issue35587) to manually test dynamic updates to RadioButton border properties at runtime.
• Introduced an automated UI test to verify that changing the border properties of a RadioButton at runtime is visually applied as expected.

Code maintenance:

• Added a missing using System.Runtime.CompilerServices; directive required for the [CallerMemberName] attribute in RadioButton.cs.

Issues Fixed

Fixes #35587

Tested the behaviour in the following platforms

• - Windows
• - Android
• - iOS
• - Mac

Output

Platform	Before	After
Windows	Before_35587Windows.mp4	After_35587Windows.mp4
Android	Before_35587Android.mov	After_35587Android.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 -- 35616

Or

• Run remotely in PowerShell:

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

[dotnet-policy-service]

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

[kubaflo]

/review -b feature/refactor-copilot-yml

[MauiBot]

Expert Review — 1 findings

See inline comments for details.

[MauiBot]

[major] Regression Prevention — This screenshot assertion is for an issue/fix explicitly affecting Windows as well as Android, but the PR only adds Android and iOS baselines; there is no TestCases.WinUI.Tests/snapshots/windows/RadioButtonBorderAppliedAtRuntime.png. On WinUI the new VerifyScreenshot() test will either fail for a missing baseline or remain unverified, so the Windows half of the regression is not covered. Please add the WinUI snapshot baseline (or split/skip Windows with an explicit reason).

[MauiBot]

🤖 AI Summary

👋 @HarishwaranVijayakumar — new AI review results are available. Please review the latest session below.

📊 Review Session — 9c32d88 · update fix · 2026-05-26 11:49 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent.

---

🧪 UI Tests — RadioButton

Detected UI test categories: RadioButton

✅ Deep UI tests — 28 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
RadioButton	28/28 ✓	—
📎 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: #35587 - [Windows, Android] Border Color and Border Width Not applying for Radio Button.
PR: #35616 - [Windows, Android] Fix Border Color and Border Width Not applying for Radio Button
Platforms Affected: Android, Windows
Files Changed: 3 implementation/API, 4 test/snapshot

Key Findings

• Runtime RadioButton.BorderColor and BorderWidth changes use bindable property names (BorderColor, BorderWidth), but RadioButtonHandler.Mapper is keyed by IRadioButton.StrokeColor and IRadioButton.StrokeThickness; initial load works because all mapper keys are applied, while runtime lookup misses.
• PR fix adds an Android/Windows RadioButton.OnPropertyChanged override and calls Handler.UpdateValue for the stroke mapper keys.
• The PR adds Android and iOS screenshot snapshots, but no Windows snapshot despite the fix and issue targeting Windows.
• Gate result provided by caller: SKIPPED — no tests detected. Gate was not re-run.

Code Review Summary

Verdict: NEEDS_CHANGES
Confidence: medium-high
Errors: 1 | Warnings: 2 | Suggestions: 0

Key code review findings:

• ❌ Missing Windows screenshot baseline for Issue35587.RadioButtonBorderAppliedAtRuntime while the issue/fix targets Windows.
• ⚠️ Android UpdateBorderDrawable only sets non-null/non-zero border values, so clearing BorderColor or setting BorderWidth <= 0 may leave stale native border state.
• ⚠️ The production fix can avoid adding a protected public API entry by aliasing at UpdateHandlerValue or mapper-registration level.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35616	Override RadioButton.OnPropertyChanged on Android/Windows and update stroke mapper keys for border property changes	⚠️ Gate SKIPPED	RadioButton.cs, PublicAPI, UI snapshots/tests	Original PR; likely fixes primary runtime apply scenario, but adds protected API and misses Windows baseline

---

🔬 Code Review — Deep Analysis

Code Review — PR #35616

Independent assessment

What this changes: RadioButton now remaps runtime BorderColor/BorderWidth property changes to the handler mapper keys IRadioButton.StrokeColor/StrokeThickness on Android and Windows. This matches the existing Button/ImageButton pattern and should fix the reported “set border at runtime” repro.

Reconciliation: PR narrative matches the code/root cause. GitHub CLI auth was unavailable, so local squashed PR diff plus GitHub MCP PR/issue data were used.

Findings

⚠️ Warning — Android runtime clearing/decreasing still appears incomplete

src/Controls/src/Core/RadioButton/RadioButton.cs:393-399 now correctly calls the Android mapper when BorderColor/BorderWidth changes, but the Android mapper path ends in RadioButtonExtensions.UpdateBorderDrawable, which only applies values when StrokeColor != null and StrokeThickness > 0. Scenario: set BorderColor = Colors.Green; BorderWidth = 3; then later set BorderColor = null or BorderWidth = 0/-1; the mapper runs, but the old Android BorderDrawable brush/width is not reset. Windows handles this more cleanly.

⚠️ Warning — Windows regression test baseline is missing

The issue is Android + Windows, and the shared test Issue35587.RadioButtonBorderAppliedAtRuntime uses VerifyScreenshot(). The PR adds Android and iOS snapshots, but no WinUI/Windows snapshot under TestCases.WinUI.Tests/snapshots/windows/, so Windows screenshot validation is incomplete or may fail when run.

Expert Reviewer Finding

❌ Error — Missing Windows screenshot baseline

src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue35587.cs:23

The HostApp issue is marked PlatformAffected.Android | PlatformAffected.UWP, and the fix targets Windows, but the PR adds Android and iOS baselines only. When this screenshot test runs on Windows, VerifyScreenshot() needs a WinUI baseline such as src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/RadioButtonBorderAppliedAtRuntime.png, or Windows should be excluded if unsupported.

Alternative fix ideas considered

• Override RadioButton.UpdateHandlerValue(...) and alias BorderColor -> StrokeColor, BorderWidth -> StrokeThickness after base.UpdateHandlerValue.
• Register mapper aliases for BorderColor and BorderWidth that dispatch to the existing stroke mapper keys.
• Android idempotent mapper cleanup is a robustness follow-up, but by itself does not trigger the missing runtime updates.

Verdict: NEEDS_CHANGES

Confidence: medium-high
Summary: The production fix likely addresses the primary runtime apply scenario, but it adds a protected API override that can be avoided and test validation has Windows/Android edge-case gaps.

---

🔧 Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix	Override RadioButton.UpdateHandlerValue to alias BorderColor/BorderWidth to stroke mapper keys; remove PR's protected OnPropertyChanged API entries	✅ Android compile passed; UI/device not runnable in environment	3 files	Best candidate: avoids new protected API and preserves Element update ordering
2	try-fix	Add controls mapper aliases for BorderColor and BorderWidth that dispatch to existing stroke mapper keys; remove PublicAPI entries	✅ Android compile passed; UI/device not runnable in environment	4 files	Also avoids new API, but less local and uses nested mapper dispatch
PR	PR #35616	Android/Windows RadioButton.OnPropertyChanged override calls stroke mapper keys for border property changes	⚠️ Gate SKIPPED	7 files	Original PR likely fixes primary apply-at-runtime repro, but adds protected API and misses Windows screenshot baseline

Cross-Pollination

Model	Round	New Ideas?	Details
code-review skill	1	Yes	Suggested UpdateHandlerValue aliasing, mapper aliasing, and Android idempotent mapper cleanup as a robustness follow-up
maui-expert-reviewer	1	Yes	Identified missing Windows screenshot baseline and validated the mapper-key root cause
maui-expert-reviewer	2	No	NO NEW IDEAS: the two meaningful abstraction-layer options are handler-update aliasing and mapper-alias registration; other variants duplicate these, bypass mapper extensibility, add public API again, or only partially fix the issue

Exhausted: Yes
Selected Fix: Candidate #1 — It is the most local alternative, avoids introducing a new protected API/PublicAPI entry, respects MAUI's Element handler-update ordering, and passed the Android compile check. It should still be paired with test coverage fixes and consideration of Android border clearing behavior.

---

📋 Report — Final Recommendation

Comparative Candidate Report

Ranking

Rank	Candidate	Result evidence	Assessment
1	pr-plus-reviewer	Android Controls.Core restore/build passed in sandbox	Best candidate. It keeps the PR's correct mapper-key fix, avoids introducing a new protected public API surface, preserves Element.UpdateHandlerValue ordering, and incorporates the strongest STEP 6a production approach. Still needs the missing WinUI screenshot baseline as a test-coverage follow-up.
2	try-fix-1	Android compile passed in STEP 6a	Best non-PR alternative. It uses the same production-code shape as pr-plus-reviewer: alias BorderColor/BorderWidth in UpdateHandlerValue and remove the new PublicAPI entries. Ranked below pr-plus-reviewer only because the reviewer-applied PR candidate carries the same improvement forward as the PR-fix candidate.
3	try-fix-2	Android compile passed in STEP 6a	Also avoids the public API addition by registering mapper aliases for BorderColor and BorderWidth. It is sound, but less local than UpdateHandlerValue and performs nested mapper dispatch from a mapper entry.
4	pr	Gate skipped; Android UI run recorded as failed/informational; no targeted pass evidence	Correctly fixes the primary bug, but ranks lower than candidates with passing Android compile evidence because it adds unnecessary protected API entries and leaves the Windows regression baseline missing.

Candidate details

pr

The raw PR fix overrides RadioButton.OnPropertyChanged on Android/Windows and calls Handler.UpdateValue(nameof(IRadioButton.StrokeColor)) for BorderColor changes and Handler.UpdateValue(nameof(IRadioButton.StrokeThickness)) for BorderWidth changes. This addresses the root mapper-key mismatch, but it adds protected API surface solely to route internal handler updates.

The shared screenshot test is useful for Android, but the issue metadata also targets Windows and the PR does not include a WinUI snapshot baseline. The recorded Android UI run failed in the broader category run, so the raw PR has no stronger validation evidence than the compile-passing alternatives.

pr-plus-reviewer

This sandbox candidate applies the expert reviewer's production-code feedback by replacing the public/protected OnPropertyChanged override with the STEP 6a UpdateHandlerValue alias. That keeps the fix inside the handler-update pipeline, avoids PublicAPI churn, and still dispatches the existing platform mapper keys for runtime border changes.

The candidate passed an Android Controls.Core restore/build in /tmp/pr35616-pr-plus-reviewer. It does not resolve the missing WinUI snapshot baseline because this environment cannot produce that image.

try-fix-1

This candidate is the strongest independent STEP 6a alternative. It uses UpdateHandlerValue to alias the bindable border property names to the existing IRadioButton stroke mapper keys and removes the unnecessary API entries. It passed Android compile in STEP 6a and has the same remaining functional caveat as pr-plus-reviewer: Android border clearing/idempotency is not improved.

try-fix-2

This candidate registers controls-layer mapper aliases for BorderColor and BorderWidth. It also passed Android compile and avoids the protected API addition, but the nested handler.UpdateValue(...) from mapper aliases is a less direct fit than centralizing the alias in UpdateHandlerValue.

Winner

pr-plus-reviewer is the single winning candidate. It combines the PR's correct root-cause fix with the best expert/STEP 6a production-code improvement and has Android compile validation. The author should still add the missing WinUI screenshot baseline before considering the regression fully covered.

---