TextInput by viridia · Pull Request #24929 · bevyengine/bevy

viridia · 2026-07-09T15:47:12Z

This PR splits the functionality of the EditableText component into two separate components: EditableText (which lives in bevy_text) and TextInput (which lives in bevy_ui_widgets).

See release notes for more details.

* FeathersLazyMenu * FeathersMenuToolButton

ickshonpe

Seems fine, agree with the overall direction. I think maybe instead of the bool param on queue_edit, we could implement an is_destructive method for TextEdit that returns true for destructive TextEdit s.

Also I haven't thought it through properly but possibly there could be problems with IME if the widget is changed to readonly during composition? I'm not sure we should worry too much though.

ickshonpe · 2026-07-10T13:20:07Z

        return;
    };

+    if *text_input == TextInput::DisplayOnly {


Suggested change

if *text_input == TextInput::DisplayOnly {

if *text_input != TextInput::Editable {

ickshonpe · 2026-07-10T13:44:34Z

@@ -360,7 +413,7 @@ fn update_ime_position(
 /// IME is enabled when an `EditableText` gains focus and disabled when focus moves elsewhere.


Needs to be updated to add that IME state also depends on TextInput now.

ickshonpe · 2026-07-10T13:51:42Z

+    mut editable_text_query: Query<&mut EditableText, With<TextInput>>,
+) {
    if let Ok(mut editable_text) = editable_text_query.get_mut(trigger.entity) {
        editable_text.queue_edit(TextEdit::clear_ime_compose());


We also need to queue TextEdit::clear_ime_compose() somewhere when TextInput changes away from Editable.

Edit: Added it to the suggested changes for listen_for_ime_input_when_text_input_focused.

ickshonpe · 2026-07-10T13:55:57Z

+    /// Cursor movement, selection, and copy to clipboard is still enabled, but no mutations are allowed
+    ReadOnly,
+    /// Display only, all interactions disabled - this is used by number input widget when dragging.
+    DisplayOnly,


Then this could be NonInteractable or something.

I also thought about Static

Co-authored-by: ickshonpe <david.curthoys@googlemail.com>

viridia · 2026-07-12T17:56:16Z

@ickshonpe @alice-i-cecile So we have a couple of outstanding issues here.

First, there's a system ambiguity which is causing the CI to fail, and which I am unsure how to fix.

Second, there's some unfinished bikeshedding around the naming and role of the TextInput component.

As I see it, we have two choices about how we can structure this:

Choice 1: EditableText is the primary component: it's a widget in it's own right (meaning, there are a bunch of observers associated with it), and the read/write mode is an auxiliary, possibly optional component. If we choose this route, then it makes sense to rename TextInput to something like TextEditable or ReadWriteMode and make it optional.

The biggest problem here is what to do about accessibility: we need to add AccessibilityNode as a required component if we are going to be consistent with the other widgets, and the only two candidates for this are EditableText and TextInput. I don't like the idea of adding a dep from bevy_text to bevy_a11y, since a11y is really about interaction, and is outside of bevy_text's wheelhouse. The only other option is to add the requirement dynamically in the plugin rather than using a Rust annotation / derive macro.

Choice 2: EditableText represents just a buffer, a passive component with no associated event listeners but lots of methods for manipulating text via queued actions; the actual "widget" is TextInput, and it, along with all of its observers, live in bevy_ui_text.

Finally, I want to mention that I need to solve this problem to unblock my work on FeathersNumberInput and the color picker dropdown generally.

…tableText.

alice-i-cecile · 2026-07-12T18:33:52Z

Responded in #24929 (comment) :) Let me know if you can't work out the resolution of the ambiguity and I'll take a look.

…25104) # Objective - Part of bevyengine#24112 ## Solution - Very straightforward port - The only thing that is slightly new is adding `Hovered` to the `FeathersRadio` helper entity to support some of this example’s functionality re: blocking drag when over a radio button. ## Testing - `cargo run --example mirror --features=“bevy_feathers”` should work the same. Strangely this functions _better_ than main for me when moving the fox. --- ## Showcase <img width="1286" height="753" alt="Screenshot 2026-07-21 at 2 23 54 PM" src="https://github.com/user-attachments/assets/dbca9793-a966-4c9f-91fa-b57e471da998" />

…WriteMode::Readonly`. This will be revisited after we refactor/rethink `InteractionDisabled`.

viridia · 2026-07-22T20:59:52Z

Looks like my latest change broke CI, not sure what caused it.

Oh, wait, I think I know.

ickshonpe · 2026-07-22T21:58:16Z

@ickshonpe @alice-i-cecile So we have a couple of outstanding issues here.

First, there's a system ambiguity which is causing the CI to fail, and which I am unsure how to fix.

Second, there's some unfinished bikeshedding around the naming and role of the TextInput component.

As I see it, we have two choices about how we can structure this:

Choice 1: EditableText is the primary component: it's a widget in it's own right (meaning, there are a bunch of observers associated with it), and the read/write mode is an auxiliary, possibly optional component. If we choose this route, then it makes sense to rename TextInput to something like TextEditable or ReadWriteMode and make it optional.

The biggest problem here is what to do about accessibility: we need to add AccessibilityNode as a required component if we are going to be consistent with the other widgets, and the only two candidates for this are EditableText and TextInput. I don't like the idea of adding a dep from bevy_text to bevy_a11y, since a11y is really about interaction, and is outside of bevy_text's wheelhouse. The only other option is to add the requirement dynamically in the plugin rather than using a Rust annotation / derive macro.

Choice 2: EditableText represents just a buffer, a passive component with no associated event listeners but lots of methods for manipulating text via queued actions; the actual "widget" is TextInput, and it, along with all of its observers, live in bevy_ui_text.

Finally, I want to mention that I need to solve this problem to unblock my work on FeathersNumberInput and the color picker dropdown generally.

I very strongly favor choice 2. I wanted it to change it to this earlier, but it felt irresponsible to demand a big refactor with the 0.19 release coming up.

viridia · 2026-07-22T22:18:45Z

Well, the tests are failing, and I'm very confused: the test that is being reported as failing (steam_osk_unidentified_keys_insert_produced_text) doesn't exist, or at least, I can't find it.

alice-i-cecile · 2026-07-22T22:26:15Z

Freshly added; I just merged in main for you.

…ut`.

kfc35

I think the transitions between drag states for the number input needs more tweaking.

While testing in feathers gallery:
When I click in to edit a number input value and then click out of it, I expected to be able to scrub the same number input, but instead it seems to insist that I still want to edit it numerically. I would expect that when I click away (lose focus) that I should be able to scrub again. Only after I press enter am I able to pointer scrub again, but the cursor doesn’t make it obvious (it has the typing cursor, not the scrubber one). It only turns back into the scrubber one after I click outside of the number input.

Overall, I think the separation of EditableText and TextInput makes sense to me. I couldn’t find any problems with read-only mode and static. The read-only mode is nice and can come in handy.

I can re-review later if you intend to fix the above problem with number input value, but I also don’t mind approving now and for that to be addressed in a (hopefully quick) follow up

kfc35 · 2026-07-24T23:59:08Z

-    if !input_focus.is_changed() {
-        return;
-    }
+    // React to removal of `TextReadWriteMode`, and drain the whole reader (using `.count()`) so that


This comment doesn’t make sense to me within the context of this function

viridia · 2026-07-25T00:35:16Z

I think the transitions between drag states for the number input needs more tweaking.

Good catch, that was a real bug; I thought I had caught that case but I missed that one (so...many...observers!). I've pushed a fix.

kfc35

I have a few suggested comments/solutions related to the what the cursor should look like under certain circumstances for the number input. Beyond that, functionally everything seems to work as expected.

kfc35 · 2026-07-25T02:52:33Z

I found that after scrubbing a number input once and then hovering back over the number input, the cursor would become the i-beam instead of staying as ColResize because technically it has focus here. I don’t think that makes sense — it should stay as ColResize unless the user has entered edit mode.

If you add a check here to ensure that the EditMode is Editing here, that solves this particular problem.

These are good suggestions - I'll try to work on them today at the club meeting.

Note that I'm not super happy with the ColResize cursor - I would prefer something lighter weight that didn't block the view so much. But unfortunately winit doesn't support the full set of standard CSS cursors: many of the standard winit cursors map to the same icon. Otherwise, I would use the standard EWResize icon, which is a bit smaller.

This specific line looks like a hold-over from the previous logic, I'm going to delete it.

DataTriny · 2026-07-26T13:45:54Z

FYI there is a big missing piece in terms of accessibility that you may want to consider early on: the content of a text input should not be set as value on the AccessKit node with Role::TextInput. Instead, nodes with Role::TextRun should be added as children of the input node for each span of text. There are a few required properties to set on these nodes: value, bounds, character_lengths, character_positions, character_widths, text_direction, optionally word_starts... Caret position or text selection is then set on the text input node, but anchor and focus refer to text run node IDs.

viridia · 2026-07-27T20:09:05Z

This was a challenging merge (text input + new theming system).

viridia · 2026-07-27T20:10:03Z

FYI there is a big missing piece in terms of accessibility that you may want to consider early on: the content of a text input should not be set as value on the AccessKit node with Role::TextInput. Instead, nodes with Role::TextRun should be added as children of the input node for each span of text. There are a few required properties to set on these nodes: value, bounds, character_lengths, character_positions, character_widths, text_direction, optionally word_starts... Caret position or text selection is then set on the text input node, but anchor and focus refer to text run node IDs.

What you are describing seems like the kind of thing that would be appropriate for a rich text editor, not a simple string editor like this.

DataTriny · 2026-07-27T20:21:05Z

What you are describing seems like the kind of thing that would be appropriate for a rich text editor, not a simple string editor like this.

All platform accessibility APIs allow assistive technologies to navigate inside text content using some form of range API. If Bevy's text inputs don't expose their content as text runs, they will appear as read-only and without caret to assistive technologies.

viridia · 2026-07-27T20:29:02Z

All platform accessibility APIs allow assistive technologies to navigate inside text content using some form of range API. If Bevy's text inputs don't expose their content as text runs, they will appear as read-only and without caret to assistive technologies.

That seems like it would be difficult to implement, as we have no concept of a "text run" in this context. While bevy does have text runs for static text blocks, for text input it's just a plain string - things like rich text or syntax highlighting have been declared out of scope, and would likely be supported by third-party crates, not the core engine.

I'm curious as to what the recommendation would be for something like a username or password login field?

DataTriny · 2026-07-27T21:20:38Z

While its API is not ideal, parley has an AccessKit integration gated behind the "accesskit" Cargo feature which can easily support small text inputs. I'm guessing that the biggest open question would be how to pick node IDs for the text runs.

viridia added 5 commits June 27, 2026 15:28

New menu-related widgets:

ef2f0ca

* FeathersLazyMenu * FeathersMenuToolButton

PR #

ab47f95

Separate EditableText into two components.

9e03953

Merge remote-tracking branch 'upstream/main' into text_input

046078e

Remove duplicative plugin in examples.

a3dca2e

viridia requested a review from ickshonpe July 9, 2026 16:20

ickshonpe reviewed Jul 10, 2026

View reviewed changes

Comment thread crates/bevy_ui_widgets/src/text_input.rs Outdated

Comment thread crates/bevy_ui_widgets/src/text_input.rs Outdated

Comment thread crates/bevy_ui_widgets/src/text_input.rs Outdated

ickshonpe reviewed Jul 10, 2026

View reviewed changes

ickshonpe suggested changes Jul 10, 2026

View reviewed changes

Comment thread crates/bevy_ui_widgets/src/text_input.rs Outdated

ickshonpe suggested changes Jul 10, 2026

View reviewed changes

Comment thread crates/bevy_ui_widgets/src/text_input.rs Outdated

ickshonpe suggested changes Jul 10, 2026

View reviewed changes

Comment thread crates/bevy_ui_widgets/src/text_input.rs

ickshonpe suggested changes Jul 10, 2026

View reviewed changes

viridia added 2 commits July 11, 2026 09:19

Review feedback (part 1).

6dc4774

Restore original formatting.

3d448c0

viridia force-pushed the text_input branch from 19ec457 to 3d448c0 Compare July 11, 2026 16:23

viridia and others added 3 commits July 11, 2026 09:26

Apply suggestions from code review

577ad78

Co-authored-by: ickshonpe <david.curthoys@googlemail.com>

Merge error.

f68c124

Missing import.

0c9d29e

Dynamically register AccessibilityNode as a required component of Edi…

cdd9180

…tableText.

github-project-automation Bot added this to UI Jul 12, 2026

github-project-automation Bot moved this to Needs SME Triage in UI Jul 12, 2026

kfc35 and others added 2 commits July 21, 2026 13:37

Merge remote-tracking branch 'upstream/main' into text_input

4f660c1

alice-i-cecile added S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Jul 22, 2026

On text inputs, treat InteractionDisabled as an alias for `TextRead…

43033fe

…WriteMode::Readonly`. This will be revisited after we refactor/rethink `InteractionDisabled`.

CI fix.

1b5781a

Merge branch 'main' into text_input

1bab811

viridia added 2 commits July 22, 2026 17:09

Fixed broken test.

a6a12a7

Moved AccessibilityNode requirement from EditableText to `TextInp…

a02d386

…ut`.

kfc35 reviewed Jul 25, 2026

View reviewed changes

Reset drag mode on focus loss.

a499c61

Remove hallucinating comment.

64ce5e8

kfc35 approved these changes Jul 25, 2026

View reviewed changes

Fix cursor logic.

f03b54b

viridia removed the S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged label Jul 25, 2026

alice-i-cecile added the S-Needs-Review Needs reviewer attention (from anyone!) to move forward label Jul 26, 2026

Merge remote-tracking branch 'upstream/main' into text_input

eec1d17

viridia added 2 commits July 27, 2026 22:21

Merge remote-tracking branch 'upstream/main' into text_input

0035718

CI

d602450

	if *text_input == TextInput::DisplayOnly {
	if *text_input != TextInput::Editable {

		@@ -360,7 +413,7 @@ fn update_ime_position(
		/// IME is enabled when an `EditableText` gains focus and disabled when focus moves elsewhere.

Uh oh!

Uh oh!

Conversation

viridia commented Jul 9, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ickshonpe left a comment • 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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ickshonpe Jul 10, 2026 • 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

viridia commented Jul 12, 2026

Uh oh!

alice-i-cecile commented Jul 12, 2026

Uh oh!

viridia commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ickshonpe commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

viridia commented Jul 22, 2026

Uh oh!

alice-i-cecile commented Jul 22, 2026

Uh oh!

kfc35 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

viridia commented Jul 25, 2026

Uh oh!

kfc35 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

DataTriny commented Jul 26, 2026

Uh oh!

viridia commented Jul 27, 2026

Uh oh!

viridia commented Jul 27, 2026

Uh oh!

DataTriny commented Jul 27, 2026

Uh oh!

viridia commented Jul 27, 2026

Uh oh!

DataTriny commented Jul 27, 2026

Uh oh!

Reviewers

ickshonpe left a comment •

edited

Loading

ickshonpe Jul 10, 2026 •

edited

Loading

viridia commented Jul 22, 2026 •

edited

Loading

ickshonpe commented Jul 22, 2026 •

edited

Loading