Visual state change for disabled RadioButton

[kubaflo]

Description of Change

Fixes #18668
Fixes #18668 (comment)

iOS	Android
Simulator.Screen.Recording.-.iPhone.15.Pro.Max.-.2024-07-07.at.02.01.55.mp4	Screen.Recording.2024-07-07.at.01.40.57.mov

[dustin-wojciechowski]

This looks good! Would you mind writing a test for it as well? :)

[kubaflo]

@dustin-wojciechowski of course, I will write the test as soon as I find some time :)

[kubaflo]

@dustin-wojciechowski I've added a UI test :)

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

/rebase

[jsuarezruiz]

/rebase

[jsuarezruiz]

Could the test change the theme and verify the disabled RadioButton on Light and Dark theme?

[kubaflo]

I'm not sure if this is necessary as changing the opacity is rather independent on user theme right?

[jsuarezruiz]

Should be a different value based on the system theme?

[kubaflo]

I think app theme is indifferent to opacity

[Copilot]

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

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

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

Or

• Run remotely in PowerShell:

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

[kubaflo]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[kubaflo]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Add TestIssue18668 visual test snapshots · 5f78785

---

Issue: #18668 - RadioButton disabled UI issue - iOS (visual state not updating when IsEnabled=false)
PR: #23471 - Visual state change for disabled RadioButton
Author: kubaflo
Platforms Affected: iOS (primary), also Android, Windows, macOS (labels on PR)
Files Changed: 1 implementation file, 3 test files, 6 snapshot files

Issue Summary

When IsEnabled = false is set on a RadioButton, the disabled visual state is not reflected in the UI on iOS. Android works correctly. The expected behavior is that the RadioButton should visually appear disabled (e.g., grayed out / reduced opacity).

Fix Approach

src/Controls/src/Core/RadioButton/RadioButton.cs - BuildDefaultTemplate() method

The PR adds:

1. Registers "Grid" name in the template's NameScope
2. Creates a Disabled visual state with an opacity setter: sets Grid.OpacityProperty to 0.4f on TargetName = "Grid"

Files Changed

Implementation:

• src/Controls/src/Core/RadioButton/RadioButton.cs (+10, -1)

Tests:

• src/Controls/tests/TestCases.HostApp/Issues/Issue18668.xaml (new)
• src/Controls/tests/TestCases.HostApp/Issues/Issue18668.xaml.cs (new)
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue18668.cs (new)

Snapshots (new): iOS, iOS-26, Android, Mac, Windows

PR Discussion Summary

author added one

• Reviewer jsuarezruiz asked: should opacity differ by theme?
• Author responded: opacity is theme-independent (both Light/Dark look identical with 0.4 opacity)
• Both review threads remain unresolved but author's responses appear reasonable

Disagreements/Open Items

File:Line	Reviewer Says	Author Says	Status
Issue18668.cs:19	Should test Light and Dark theme	Opacity is theme- Unresolved	independent
RadioButton.cs:640	Should opacity differ by theme	App theme is indifferent to Unresolved	opacity

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #23471	Add Disabled VSM state with Grid.Opacity = 0.4f to default RadioButton PENDING (Gate)	RadioButton.cs (+10, -1)	Cross-platform fix via default template	template

---

🚦 Gate — Test Verification

---

📝 Review Session — Add TestIssue18668 visual test snapshots · 5f78785

---

Result PASSED:
Platform: ios
Mode: Full Verification

• Tests FAIL without fix
• Tests PASS with fix

Test: Issue18668 - TestIssue18668() - screenshot verification of disabled RadioButton opacity

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Add TestIssue18668 visual test snapshots · 5f78785

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-sonnet-4.6)	Imperative in and	PASS	RadioButton.cs (+13)	Works but bypasses VSM entirely
2	try-fix (claude-opus-4.6)	Data binding with on template root	PASS	RadioButton.cs (+15)	MAUI-idiomatic but adds a converter class
3	try-fix (gpt-5.2)	Per-element VSM opacity setters (ellipse, checkmark, contentPresenter) + for checkmark toggle	PASS	RadioButton.cs (+~20)	More surgical but more complex; changes checkmark toggle mechanism
4	try-fix (gpt-5.3-codex)	iOS handler-level / with when disabled	PASS	RadioButtonHandler.cs (+4), RadioButtonHandler.iOS.cs (+14)	Platform-specific; modifies handler files rather than shared code
5	try-fix (gemini-3-pro-preview)	Imperative in behind guard	PASS	RadioButton.cs (+18)	iOS-only guard is a concern; coupling to template structure in code
(separate from VSM pipeline)	PASS	RadioButton.cs (+7)	Clean declarative; Trigger reverts automatically when re-enabled
PR	PR #23471	VSM state setter: via in	PASS (Gate)	RadioButton.cs (+10, -1)	Original PR; pure VSM declaration; minimal, idiomatic

Exhausted: Yes (2 cross-pollination rounds; 2/5 models confirmed NO NEW IDEAS in round 2; remaining ideas are color-based/timing variations)

Selected Fix: PR's It is the simplest, most idiomatic approach: pure VSM declaration that slots naturally into the existing VSM infrastructure already present in BuildDefaultTemplate(). All alternatives either add complexity (converter classes, handler overrides, platform guards) or change unrelated behavior (checkmark visibility mechanism). The PR's approach is minimal, cross-platform, and consistent with the existing code style.fix

Cross-Pollination Summary

ran Attempt 6 (Trigger approach)
Round 2: 2/5 NO NEW IDEAS; remaining suggestions were color-based (Stroke/Fill) and timing incremental, not fundamental; max exploration reachedvariations

---

📋 Report — Final Recommendation

---

📝 Review Session — Add TestIssue18668 visual test snapshots · 5f78785

---

Final Recommendation: APPROVE (with minor code quality notes)

Summary

PR #23471 fixes a real bug (issue #18668) where the RadioButton's disabled visual state had no iOS showed no visual change when IsEnabled = false while Android worked correctly. The fix adds a Disabled VSM state with Grid.Opacity = 0.4f to the default RadioButton template. Gate verification confirmed tests correctly catch the bug: they fail without the fix and pass with the fix. Six independent try-fix approaches were explored; all six passed, confirming multiple viable solutions. The PR's approach was selected as the simplest and most idiomatic.setters

Root Cause

The default RadioButton template (BuildDefaultTemplate) declared a Disabled VisualState but with no the state existed but had no visual effect. When IsEnabled = false, the VSM transitioned to the Disabled state successfully, but nothing changed visually. Android has platform-specific handler behavior that applied disabled appearance independently of VSM; iOS did not, exposing the gap in the shared template.setters

Fix Quality Correct Approach:

The PR adds:

1. nameScope.RegisterName("Grid", registers the inner Grid so VSM can target itgrid)
2. A Setter in the Disabled state: Grid.OpacityProperty = 0.4f on TargetName = "Grid"

This is the minimal, idiomatic fix: pure VSM declaration in BuildDefaultTemplate, consistent with the existing Checked/Unchecked state setters already in the same method. Six alternative approaches (imperative, binding, trigger, per-element, platform handler, platform-guarded) all passed tests, validating that the fix space is correct. The PR's declarative VSM approach is the simplest.

Code Review Findings

The new code block mixes tab-indented first line with space-indented subsequent lines:####

// Line 1: tab-indented (correct)
VisualState disabledVisualState = new VisualState() { Name = VisualStateManager.CommonStates.Disabled };
// Lines 2-8: space-indented (inconsistent with surrounding code using tabs)
            disabledVisualState.Setters.Add(
                new Setter()
                {
                    Property = Grid.OpacityProperty,
                    TargetName = "Grid",
                    Value = 0.4f
                });
            common.States.Add(disabledVisualState);

Recommendation: Convert the indentation to tabs to match the rest of the file (and the surrounding Checked/Unchecked setters pattern).

An existing Mac test snapshot (RadioButtonWithValueChangeSelected.png) was modified in this PR. This could be a legitimate ripple effect from the opacity change affecting a pre-existing checked RadioButton, or it could be an unintended regression. The PR description does not mention this. Recommend: author should confirm this snapshot change is expected and intentional.####

VerifyScreenshot() is the correct pattern

• Screenshot-based verification is appropriate for this visual bug
• [Category(UITestCategories.RadioButton)] is correct
• Platform snapshots added for iOS, iOS-26, Android, Mac, good cross-platform coverageWindows

The PR description is minimal (no NOTE block). The required NOTE block for community testing should be added:####

> [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you!

PR Title Assessment

Current: "Visual state change for disabled RadioButton"
Assessment: Acceptable. Could be more specific (RadioButton: Add Disabled visual state opacity) but current title is clear enough. The issue is cross-platform so no platform tag is warranted.

Open Review Threads Assessment

Two unresolved threads from jsuarezruiz:
Author is correct: opacity reduction is theme-agnostic. Light and dark mode images both show the same 0.4 opacity result looks good. No change needed.
Author is correct: since the fix is opacity-only and theme-independent, separate theme tests add no value. No change needed.

Verification Results

Check	Result
Gate: Tests FAIL without fix
Gate: Tests PASS with fix
Platform tested	iOS
try-fix: 6 independent approaches	All PASS
Selected fix	PR's fix (simplest, most idiomatic)

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: Visual state change for disabled RadioButton

Description: ✅ Good

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

The default RadioButton template (BuildDefaultTemplate() in RadioButton.cs) declared a Disabled VisualState but with no setters. When IsEnabled = false, the VisualStateManager successfully transitioned to the Disabled state, but nothing changed visually because no property was being set. Android's platform handler independently applied disabled appearance; iOS and MacCatalyst did not, so the RadioButton appeared fully active even when disabled.

Description of Change

Adds a visual disabled state to the RadioButton default template:

1. RadioButton.cs — BuildDefaultTemplate():
   • Registers "Grid" in the template's NameScope so the VisualStateManager can target it by name
   • Adds a Setter to the Disabled VisualState that reduces Grid.Opacity to 0.4f, giving a clear visual indication that the control is disabled

The change is in the shared cross-platform template, so all platforms benefit: iOS, Android, macOS/MacCatalyst, and Windows will all show the opacity reduction when a RadioButton is disabled.

Note: An existing Mac snapshot (RadioButtonWithValueChangeSelected.png) was also updated as a side-effect of this change — the new opacity registration may affect how the Mac renders the selected state visually.

Issues Fixed

Fixes #18668

Platforms Tested

• iOS
• Android
• macOS / MacCatalyst
• Windows

Code Review: ✅ Passed

Code Review — PR #23471

PR: Visual state change for disabled RadioButton

---

🟡 Minor Issues

1. Indentation Inconsistency

File: src/Controls/src/Core/RadioButton/RadioButton.cs
Lines: 636–644 (the new Disabled VSM block)

The new code uses 4-space indentation, while the rest of BuildDefaultTemplate() (and the file overall) uses tabs. This creates a mixed-indentation block that is inconsistent with the surrounding code style.

Current (problematic):

// Tab-indented (correct, matches surrounding code):
VisualState disabledVisualState = new VisualState() { Name = VisualStateManager.CommonStates.Disabled };
// Space-indented (inconsistent):
            disabledVisualState.Setters.Add(
                new Setter()
                {
                    Property = Grid.OpacityProperty,
                    TargetName = "Grid",
                    Value = 0.4f
                });
            common.States.Add(disabledVisualState);

Recommendation: Convert the space-indented lines to tabs to match the rest of the file. The dotnet format command should catch this:

dotnet format Microsoft.Maui.sln --no-restore --exclude Templates/src --exclude-diagnostics CA1822

---

2. Modified Unrelated Mac Snapshot — Needs Confirmation

File: src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/RadioButtonWithValueChangeSelected.png

This pre-existing snapshot was modified by this PR. The PR description does not mention this change. This could mean:

• The opacity change to the Grid inadvertently affects how the normal/selected state renders on Mac (e.g., due to how the NameScope registration changes template behavior), or
• It is a legitimate rendering update that just needed a baseline refresh.

Recommendation: The author should explicitly confirm in the PR that this snapshot change is expected and intentional, and briefly explain why the selected-state visual changed. If unexpected, the root cause should be investigated before merging.

---

✅ Looks Good

• Fix approach is idiomatic: Using the VisualStateManager with a declarative Setter in BuildDefaultTemplate() is the correct, minimal pattern consistent with the existing Checked/Unchecked state infrastructure in the same method.
• NameScope registration is correct: nameScope.RegisterName("Grid", grid) follows the same pattern already used for UncheckedButton, CheckedIndicator, and ContentPresenter.
• Opacity value (0.4f): A reasonable disabled-state opacity. It is theme-independent, which is correct — opacity reduction works equally well on light and dark backgrounds.
• Cross-platform test coverage: Screenshot snapshots added for iOS, iOS-26, Android, Mac, and Windows — good coverage for a visual change.
• Test structure: VerifyScreenshot() after disabling is the correct pattern for a visual regression test. [Category(UITestCategories.RadioButton)] is appropriate.

---

ℹ️ Context: Open Review Threads

There are two unresolved review threads from reviewer jsuarezruiz:

Thread	Reviewer Question	Author Response	Assessment
Issue18668.cs:19	Should the test verify both Light and Dark theme?	Opacity is theme-independent; dark/light look the same with 0.4 opacity	Author is correct — opacity reduction is visually consistent across themes. No separate theme test is needed.
RadioButton.cs:640	Should opacity differ by system theme?	App theme is indifferent to opacity	Author is correct — using a fixed 0.4f opacity regardless of theme is the right approach for a disabled state indicator.

Both threads can be resolved without code changes. The author's reasoning is sound.

---