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 · 2026-07-10T10:11:21Z

+pub enum TextInput {
+    /// Text input functions normally
+    #[default]
+    Editable,
+    /// 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,
+}


I don't like the variant names either. Not sure I have any better suggestions though, probably not worth fussing about.

Yeah these are fine.

ickshonpe · 2026-07-10T10:18:24Z

+#[require(EditableText)]
+#[require(AccessibilityNode(accesskit::Node::new(Role::TextInput)))]
+#[reflect(Component)]
+pub enum TextInput {


I think this should be called something like TextInputMode or TextInputInteractionState. The name TextInput suggests that this is the primary text input component. But it's not part of the user-facing API, it's used for tracking the input's interaction state internally.

OK so here's the problem I have: this component does more than just control the readonly mode - it also pulls in the AccessibilityNode required component. If I were to rename this to ReadWriteMode as we discussed, then this required component doesn't make sense, and I'd have to move it to EditableText. But I'm not sure if bevy_text should be pulling in accessibility - it depends on whether you consider EditableText to be a widget, or just a buffer.

Worse, if this truly is just a mode switch and not a "widget" then it probably should be optional, which means I definitely can't put the accessibility node required component here.

IMO this should just be an optional mode-switch, and not pull in accessibility components. Those should be attached to the actual widgets.

Strong preference for TextInputMode as a name; we can't use TextInput for something like this because it makes it seem too important.

ickshonpe · 2026-07-10T11:25:11Z


-    let mut queue_edit = |edit| {
-        if keyboard_input.input.state.is_pressed() {
+    let mut queue_edit = |edit, readonly| {


The readonly param feels a bit error prone. It'd be clearer with two functions queue_edit and queue_read_only or something but it'd need to use a RefCell or macro.

Maybe we could have a separate function that returns true if a TextEdit is destructive that we can filter by in queue_edit?

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:03:07Z

+        if *text_input == TextInput::Editable
+            || (readonly && *text_input == TextInput::ReadOnly)
+                && keyboard_input.input.state.is_pressed()
+        {


It doesn't check is_pressed in TextInput::Editable mode. It doesn't double enter characters because the

if let Some(text) = &keyboard_input.input.text

guard fails, but everything else like cursor and delete inputs are applied on release as well as press now.

Suggested change

if *text_input == TextInput::Editable

|| (readonly && *text_input == TextInput::ReadOnly)

&& keyboard_input.input.state.is_pressed()

{

if keyboard_input.input.state.is_pressed()

&& (*text_input == TextInput::Editable

|| (readonly && *text_input == TextInput::ReadOnly))

{

ickshonpe · 2026-07-10T13:05:21Z

-        (COMMAND, Key::Character(c)) if c.eq_ignore_ascii_case("x") => queue_edit(TextEdit::Cut),
        (COMMAND, Key::Character(c)) if c.eq_ignore_ascii_case("v") => {
-            queue_edit(TextEdit::Paste);
+            queue_edit(TextEdit::Paste, true);


Suggested change

queue_edit(TextEdit::Paste, true);

queue_edit(TextEdit::Paste, false);

ickshonpe · 2026-07-10T13:11:19Z


+    if *text_input != TextInput::Editable {
+        return;
+    }


Need to the drain IME reader the same as with the other guards.

Suggested change

}

if *text_input != TextInput::Editable {

// Still need to drain the reader to prevent stale events on next focus.

ime_reader.read().for_each(drop);

return;

}

Maybe it would be more robust if we consolidated the three guards and just drain one time.

I thought about this, but even though they have the same effect, the comments in the blocks are different.

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:54:53Z

+    #[default]
+    Editable,
+    /// Cursor movement, selection, and copy to clipboard is still enabled, but no mutations are allowed
+    ReadOnly,


Maybe:

Suggested change

ReadOnly,

NavigableOnly,

One reason for preferring ReadOnly is that it's consistent with the behavior of the HTML readonly attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/readonly

Yep, it's fine. It's not user facing and the doc comments are clear about the meaning of each variant.

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.

ickshonpe · 2026-07-13T07:42:29Z

+            | TextEdit::BackspaceWord
+            | TextEdit::Delete
+            | TextEdit::DeleteWord
+            | TextEdit::ImeSetCompose {


This is a bit annoying because technically ImeSetCompose isn't destructive I guess, depending on how you think about it. But pragmatically it should be on this side.

Though thinking about it, the readonly and IME modes are meant to be mutually exclusive. If is_destructive gets called on ImeSetCompose, it might be indicative of an error and maybe we should emit a warning. It's not important for this PR though, I'll just make a note of it and look into later.

ickshonpe · 2026-07-13T08:09:26Z

@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 think that neither EditableText nor ReadWriteMode (assuming it's renamed) should be the primary component. Instead we should add another a new component TextInput that acts as the primary component and carries all the widget specific requirements. It can just be a zst for now, but later can we can migrate the customisation fields over to it from EditableText.

Read-only state is now controlled by `TextReadWriteMode`.

viridia · 2026-07-14T22:02:48Z

I restructured TextInput based on our discussion, it's now a marker component, with a separate TextReadWriteMode enum.

@ickshonpe This was a difficult merge, so please make sure I didn't screw anything up.

I don't know a lot about IMEs, and the logic for detecting writeable / read-only transitions got a lot gnarlier now that TextReadWriteMode is optional - I needed to also detect component removal.

viridia · 2026-07-14T22:09:59Z

Also, I'm not sure how to fix the system ambiguity with the ImeSystems sets.

ickshonpe · 2026-07-16T16:28:59Z

        // These components cannot be registered in `bevy_text` where `EditableText` is defined,
        // because that would create a circular dependency between `bevy_text` and `bevy_ui`.
        app.register_required_components::<EditableText, Node>()
            .register_required_components::<EditableText, TextNodeFlags>()
+            .register_required_components_with::<EditableText, AccessibilityNode>(|| {
+                AccessibilityNode(accesskit::Node::new(Role::TextInput))
+            })
            .register_required_components::<EditableText, ContentSize>();


These requirements can be moved onto TextInput now?

ickshonpe · 2026-07-16T16:41:25Z

 fn listen_for_ime_input_when_text_input_focused(
    input_focus: Res<InputFocus>,
-    editable_text_query: Query<(), With<EditableText>>,
+    mut removed_rwmode: RemovedComponents<TextReadWriteMode>,


Is there a reason for not just requiring TextReadWriteMode on TextInput? RemovedComponents is such a pain, supporting TextReadWriteMode for all text input types might be simpler.

ickshonpe

I made a branch for testing where I added a TextReadWriteMode menu to the multiline_text_input example:

https://github.com/ickshonpe/bevy/tree/24929-textreadwritemode-example

In static mode, selection and scrolling is still possible if the text is longer than the view and you drag outside of the input.

viridia · 2026-07-16T19:33:16Z

I made a branch for testing where I added a TextReadWriteMode menu to the multiline_text_input example:

Based on the discussion on discord, we might instead change this to be a pair of marker components, one of which is the pre-existing InteractionDisabled. This will be a PITA to implement (more component removal detection, yuck), but minimizes the number of new concepts being introduced.

viridia · 2026-07-20T17:05:39Z

I've updated the multiple_text_inputs example to include the readonly and static variants:

In the process of developing this PR, I have learned a bunch of things:

My idea of using InteractionDisabled to mean either ReadOnly or Static didn't work out: in the current feathers code, InteractionDisabled causes an appearance change ("graying out"), and I needed a way to disable editing without this.
I've also found a number of bugs and incorrect code, which I've attempted to address. For example, some headless widgets were setting focus to themselves, and others were not - but this was all useless code, because the global "click-to-focus" observer was already doing this.
Also, I realized that the "click-to-focus" observer lives in a lower-level crate (bevy_input_focus), and because of this it cannot depend on InteractionDisabled which lives in bevy_ui. (Input focus is meant to work with 2d and 3d objects as well as UI, so it cannot depend on marker components in UI.)
I think that eventually we will need to rename InteractionDisabled to make it less confusing, and possibly split it into two separate components - one which makes the widget non-focusable, and one which makes it non-operable. This avoids arguments about the meaning of the word "interaction".
I've also realized that there are subtle differences between the strict interpretation of the W3C accessibility guidelines, and the common behavior of many UI frameworks (both web and native). There is a lot of inconsistency here, and no clear policy about which set of standards Bevy should adhere to.
For the moment I have decided to simply document the current behavior and move on.

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

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

ickshonpe reviewed Jul 13, 2026

View reviewed changes

viridia added 2 commits July 14, 2026 10:12

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

43e5de2

TextInput is now a marker.

2d79408

Read-only state is now controlled by `TextReadWriteMode`.

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

ickshonpe reviewed Jul 16, 2026

View reviewed changes

viridia marked this pull request as draft July 17, 2026 01:19

viridia mentioned this pull request Jul 17, 2026

FeathersNumberInput can't be used in a popup #24812

Open

viridia added 3 commits July 19, 2026 12:33

Make TextReadWriteMode a required component of EditableText.

a6a83d3

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

3ac5b70

Bug fixes, improved example

1dfbac3

Add ordering for IME system sets.

547fb2d

	queue_edit(TextEdit::Paste, true);
	queue_edit(TextEdit::Paste, false);

-    }
+    if *text_input != TextInput::Editable {
+        // Still need to drain the reader to prevent stale events on next focus.
+        ime_reader.read().for_each(drop);
+        return;
+    }

	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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

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!

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!

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ickshonpe commented Jul 13, 2026

Uh oh!

viridia commented Jul 14, 2026

Uh oh!

viridia commented Jul 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

ickshonpe Jul 10, 2026 •

edited

Loading

ickshonpe left a comment •

edited

Loading

ickshonpe Jul 10, 2026 •

edited

Loading

ickshonpe Jul 10, 2026 •

edited

Loading

ickshonpe left a comment •

edited

Loading