Make Radio Button behaviour modular and consistent with other widgets #21294

PPakalns · 2025-09-30T09:23:12Z

Objective

Fixes #21261

Solution

Changes:

Detect events directly on radio buttons,
Make RadioGroup optional,
ValueChange events are triggered on checked radio button and RadioGroup.

This makes radio button behavior:

similar to other widgets, where we can observe triggered change directly on widget,
radio button widget can function separately,
modular, users can decide if they want to use RadioGroup or want to roll out their own solution.

Current behavior in examples doesn't change with this PR.

Testing

Tested using existing examples. See feathers example, behavior doesn't change.
Additionally, tested in bevy_immediate where widget consistency is useful.

viridia · 2025-10-01T02:21:26Z

crates/bevy_ui_widgets/src/radio.rs


-            // Trigger the on_change event for the newly checked radio button
+            // Trigger the value change event on the radio button
+            commands.trigger(ValueChange::<bool> {


This seems like an odd way to use ValueChange:

If the value is always the same (true), then we should trigger Activate instead. Activate is meant for widgets whose state never changes.

Alternatively, we could trigger ValueChange(false) when the button gets deselected because of mutual exclusion. However, that's more complicated because now you would have to pass around the entity id of the previously checked button (which is not a problem here, but might be further down).
More generally, if we're going to use ValueChange, it should always reflect the current state of the widget triggering it: a listener that only listens to ValueChange should always know what state the source is in. We can't do this if it only sends ValueChange for some state transitions and not others.

We can use Activate. But i used ValueChange instead because all other Checkable widgets raise ValueChange event.

And for me it seemed logical to think that RadioButton can only be checked by interacting with it. To uncheck it users need to add other widgets / radio group / logic that can uncheck it.

So I would prefer ValueChange<bool> because all checkable widgets use that event.

EDIT: P.S. But activate is fine with me too.

viridia · 2025-10-01T02:29:29Z

crates/bevy_ui_widgets/src/radio.rs

-                    break;
-                }
-            }
+    let Ok(checked) = q_radio_button.get(ev.focused_entity) else {


One consequence of bailing out here is that disabled radio buttons no longer consume the SPACE/ENTER keyboard event, instead the event will propagate to the ancestors.

See answer to
#21294 (comment)

Currently we have different behaviour for keyboard and clicks which is probably a bug in current implementation.

I used clicks as a reference implementation.

Fixed in 9806468

viridia · 2025-10-01T02:33:07Z

crates/bevy_ui_widgets/src/radio.rs

+    q_parents: Query<&ChildOf>,
+    mut commands: Commands,
+) {
+    let Ok(checked) = q_radio.get(ev.entity) else {


Bailing out here means that a disabled radio button doesn't consume the click event, which will propagate to the ancestors. In other words, it will cause the click to trigger on whatever container entity holds the radio button, which I think is probably incorrect.

I think that disabled widgets shouldn't behave as if the widget was absent; rather, they should behave as if the widget was read-only. This means that they still receive click events, they just don't respond to them.

This is why I used Has<InteractionDisabled> rather than Without<InteractionDisabled> - so that I could detect clicks on disabled buttons and stop propagation on them.

I tried to implement behaviour based on the current click implementation for radio group / button.

Current implementation doesn't cancel click event propagation on a disabled widget.

bevy/crates/bevy_ui_widgets/src/radio.rs

Lines 176 to 196 in eac8bc7

// Radio button is disabled.

if q_radio.get(radio_id).unwrap().1 {

return;

}

// Gather all the enabled radio group descendants for exclusion.

let radio_buttons = q_children

.iter_descendants(ev.entity)

.filter_map(|child_id| match q_radio.get(child_id) {

Ok((checked, false)) => Some((child_id, checked)),

Ok((_, true)) | Err(_) => None,

})

.collect::<Vec<_>>();

if radio_buttons.is_empty() {

return; // No enabled radio buttons in the group

}

// Pick out the radio button that is currently checked.

ev.propagate(false);

let current_radio = radio_buttons

I can fix that too in this PR.

Fixed in 9806468

github-actions · 2025-10-01T18:35:20Z

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

viridia · 2025-10-03T21:02:29Z

Apologies for not responding on this, I haven't forgotten about it.

viridia

Apologies for the delay. I finally had a chance to check this out locally and verify that the keyboard navigation behavior still worked as expected.

alice-i-cecile

I'm happy with this now, but it needs a migration guide :) The changes here are quite subtle and won't result in compiler errors.

Make Radio Button behaviour modular and consistent with other widgets

49e7053

viridia reviewed Oct 1, 2025

View reviewed changes

alice-i-cecile added this to the 0.18 milestone Oct 1, 2025

Fix bug with event propagation cancellation

9806468

viridia approved these changes Oct 6, 2025

View reviewed changes

alice-i-cecile requested changes Oct 6, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Make Radio Button behaviour modular and consistent with other widgets #21294

Make Radio Button behaviour modular and consistent with other widgets #21294

PPakalns commented Sep 30, 2025 •

edited

Loading

Uh oh!

viridia Oct 1, 2025

Uh oh!

PPakalns Oct 1, 2025

Uh oh!

PPakalns Oct 1, 2025 •

edited

Loading

Uh oh!

viridia Oct 1, 2025

Uh oh!

PPakalns Oct 1, 2025

Uh oh!

PPakalns Oct 2, 2025 •

edited

Loading

Uh oh!

viridia Oct 1, 2025

Uh oh!

PPakalns Oct 1, 2025

Uh oh!

PPakalns Oct 2, 2025

Uh oh!

github-actions bot commented Oct 1, 2025

Uh oh!

viridia commented Oct 3, 2025

Uh oh!

viridia left a comment

Uh oh!

alice-i-cecile left a comment

Uh oh!

Uh oh!

	// Radio button is disabled.
	if q_radio.get(radio_id).unwrap().1 {
	return;
	}

	// Gather all the enabled radio group descendants for exclusion.
	let radio_buttons = q_children
	.iter_descendants(ev.entity)
	.filter_map(\|child_id\| match q_radio.get(child_id) {
	Ok((checked, false)) => Some((child_id, checked)),
	Ok((_, true)) \| Err(_) => None,
	})
	.collect::<Vec<_>>();

	if radio_buttons.is_empty() {
	return; // No enabled radio buttons in the group
	}

	// Pick out the radio button that is currently checked.
	ev.propagate(false);
	let current_radio = radio_buttons

Uh oh!

Make Radio Button behaviour modular and consistent with other widgets #21294

Are you sure you want to change the base?

Make Radio Button behaviour modular and consistent with other widgets #21294

Conversation

PPakalns commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Testing

Uh oh!

viridia Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

viridia Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

viridia Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

PPakalns Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Oct 1, 2025

Uh oh!

viridia commented Oct 3, 2025

Uh oh!

viridia left a comment

Choose a reason for hiding this comment

Uh oh!

alice-i-cecile left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

PPakalns commented Sep 30, 2025 •

edited

Loading

PPakalns Oct 1, 2025 •

edited

Loading

PPakalns Oct 2, 2025 •

edited

Loading