Native Text Input

Unity’s own text editing loses on all three platforms, each for a different reason:

The things users notice most (place the caret by tapping once, drag to select, long-press for Paste, autofill a password) are only possible if a real OS text view receives the touch. That single requirement drives most of the design decisions below.

The invariant that ties it together: exactly one renderer draws the text at any moment. The inner UI Toolkit text element is blanked (opacity: 0, never visibility, see Visibility and suppression) whenever the native view is showing. Because value is always mirrored, either renderer can take over on any frame — which is what makes the editor path, the suppressed path (see Visibility and suppression) and a disabled field all work with no special cases.

That invariant is why Fonts matters: every suppression swaps renderers, and a swap between Figtree-in-UITK and whatever the OS would otherwise pick is a visible pop. Both renderers now draw the same face, so the swap is invisible — which is the only reason it can be used as freely as it is here.

[[Authoring the box]] === Authoring the box

It also decides where a field’s USS goes, and getting it wrong fails silently and only on device:

The box goes on the field; only text properties go on the inner input. Size, padding, background, border and corner radius belong on the element carrying your own class. The inner .unity-base-text-field__input is the element that gets blanked, so a background or radius painted there vanishes for exactly as long as the field is in use and comes back the moment anything suppresses the native view — which reads as "the field loses its background while I type". Colour, font size, weight and alignment do belong on the inner element, because that is where UI Toolkit resolves them for the text and where Style transfer reads them back.

Padding on the field rather than the input is not just tidier, it is what the frame maths expects: the native inset is derived as the difference between the two boxes (see Coordinates), so padding authored on the field is what puts the native glyphs where UI Toolkit would have drawn them.

Author the margin. TextField carries a horizontal margin from the theme, so a field left to inherit it stands narrower than everything around it.

.input-modalfield (MultimodalStyles.uss), .chatfield / .chattext (ConversationStyles.uss) and .debug-infosearch (DebugInfoStyles.uss) are all the same recipe.

WebKeyboard.jslib is unrelated and stays: it backs plain TextField`s (debug UIs) through Unity’s `JS_MobileKeyboard_* hooks.

One id-keyed registry per platform, one shape for all three. Every call is C# → native; every event is native → C#, pushed, never polled.

Events arrive on the INativeTextInputListener handed to Create, so the platform layer resolves the id and the UI layer never keeps a table of its own. BetterTextField implements it explicitly: the four methods are the native side’s business, not the element’s API.

Transport follows the conventions of its neighbours in SystemNative (WebView.cs is the reference): [DllImport("__Internal")] plus MonoPInvokeCallback statics on iOS, makeDynCall in .jslib on Web, AndroidJavaProxy marshalled through SynchronizationContext.Post on Android. Callbacks are static and id-keyed, not per-instance delegates, to keep IL2CPP happy and avoid one GC handle per field.

BetterTextField keeps a static registry of every attached field and ticks it from a LateUpdate, the same hook LiquidGlassManager uses to keep its scopes on top of moving chrome, and for the same reason: the things that move UI are transforms and ancestor layout, and neither fires a GeometryChangedEvent on the field itself. A field inside a SafeAreaContainer whose content margins ease as the keyboard opens never sees a local layout change, so an event-driven sync would latch at the wrong position for the whole animation.

The LateUpdate comes from a hidden GameObject created on demand by the first field to attach, so a field works inside a popup instantiated at runtime with no owning MonoBehaviour — the same self-sufficiency the Web overlay had. It is the only reason a GameObject is involved at all.

Per registered field, per frame:

Everything is diffed, so a static screen full of fields costs a handful of float comparisons. The per-element schedule.Execute(…​).Every(16) ticks in today’s implementation go away.

A freshly attached field re-pushes everything unconditionally for its first WarmupTicks ticks instead of relying on the diff. On Android the native view is created a post behind the call that returned its id, so the first diffed pushes can land before anything is listening for them; a field never repeats a push on a static screen otherwise, so nothing is lost by forcing it for a handful of frames after attach.

A native view sits above the entire Unity surface. It has no idea that a popup opened over its field, and — since it is interactive — it would keep eating touches there. Correctness here is an input bug, not a cosmetic one, so it is layered:

Those three are the whole list. An explicit, ref-counted Suppress() scope for anything else — a decorative picking-mode: ignore overlay, a screen transition — was written and then removed unused: nothing in the app ever opened one. It is roughly fifteen lines (a counter, a check in the predicate, and an IDisposable) the day something genuinely needs it.

Suppression hides the native view and blurs it, and UI Toolkit resumes drawing the text. The same path covers SetEnabled(false), so a disabled field is simply "UI Toolkit renders, greyed, via USS".

Two further rules keep the decision from turning into a flicker, because withdrawing a view blurs it and a blur drops the keyboard mid-sentence:

While shown, the native view is interactive and receives the touch directly. This is what buys first-tap caret placement, drag-select and long-press menus — and on Web it is not optional: iOS Safari only raises the keyboard when focus() happens inside the browser’s own gesture handler, which a Unity-side PointerDownEvent (dispatched a frame later, outside the DOM event) can never satisfy. Programmatic focus works fine on iOS and Android, so this rule is uniform only because uniform is simpler, not because all three demand it.

The handshake, guarded by a reentrancy flag on both sides:

UI Toolkit must never open its own keyboard, so on device the field runs with textEdition.isReadOnly = true and textEdition.hideSoftKeyboard = true. isReadOnly does not block programmatic value writes, which is exactly what the mirror needs, and hideSoftKeyboard is what TextElement checks before opening a TouchScreenKeyboard behind our back. Today’s hideMobileInput = true and the mobile-native-input tap-catcher child both become unnecessary.

The Web keyboard focus guard (a capture-phase mousedown/touchstart that `preventDefault()`s taps at or below the focused input, so tapping send does not dismiss the keyboard) is unchanged, and still fed by the pushed frame.

One fix falls out of the focus handshake: WebGLInput.captureAllKeyboardInput must be ref-counted on focus, not on visibility as today. Keying it to visibility disables every Unity keyboard shortcut on desktop Web for as long as a chat input is on screen. Focus is both sufficient (DOM focus precedes the first keydown) and necessary (Unity’s capture-phase listener would otherwise preventDefault the keystroke before the input sees it).

The native view is the only thing that knows where its text wraps, so it is authoritative for height and nothing else:

The loop terminates because content height is a function of width only, and only height is ever written. A half-pixel threshold keeps it from oscillating on rounding.

The chat composer is the growing field. It is authored multiline="true" auto-grow="true" return-key="Submit" — it wraps and grows, but return still sends rather than breaking a line, which keeps Submitted meaning what it meant before and keeps a Send key on the keyboard. Growth therefore comes from wrapping alone; there is no way to type an explicit newline into a message, which is the same trade the field made when it was single-line.

That combination is the one place Android needs care: TYPE_TEXT_FLAG_MULTI_LINE makes the IME replace its action key with a newline key, so a field that wraps and submits asks for neither singleLine nor MULTI_LINE — it turns horizontal scrolling off, which wraps, and keeps the Send action. Return is caught separately by a key listener so nothing inserts a line.

In ConversationStyles.uss the pill’s height became min-height, the row’s buttons moved to its bottom edge (align-items: flex-end, and align-self: flex-end on the send button, which at the resting height is the same 6 px inset centring gave it), .chat__text gained the vertical padding that gives a grown pill its breathing room, and the radius is deliberately unchanged at every height — the usual chat look. The cap is a new token, --chat-input-max-text-height: 120px, five lines of --line-height-larger, applied as a max-height on the inner element.

The multimodal input popup stays single-line and does not grow: it prompts for a name or an email, and its return key still submits. AutoGrow following multiline is what makes that the default.

Authoring rules that follow, and that a growing field must respect:

Pushed from resolvedStyle whenever it changes: fontSize, color, unityFontStyleAndWeight, unityTextAlign (both axes), letterSpacing, plus textSelection.cursorColor and selectionColor — which are USS custom properties (--unity-cursor-color, --unity-selection-color), so caret and selection colour stay authorable. Placeholder colour comes from the same place UI Toolkit takes it.

Not transferred, and not supported: rotation and skew (the frame is an axis-aligned box; scale and translation survive because they are baked into worldBound), per-character rich text, and UI Toolkit text outline/shadow. A BetterTextField is plain text by definition.

With no backend compiled in, BetterTextField is a TextField: UI Toolkit renders and edits, isReadOnly/hideSoftKeyboard are never set, growth comes from UI Toolkit’s measurement. The only addition is a trickle-down KeyDownEvent handler that fires Submitted on Enter for single-line fields, so Submitted means the same thing everywhere. This is what the mobile-native-input branch already does and it works.

Drop-in for the properties the app actually uses, by mapping them instead of reinventing them:

New members: Submitted (as before), ReturnKey, AutoGrow and Autocorrect (all UxmlAttribute`s), and `SelectAllText/SelectTextRange.

Autocorrect (autocorrect in UXML) is this element’s own attribute rather than textEdition.autoCorrection, for two reasons: it defaults to off — welcome in a chat message, a nuisance in a name, an email or a code, and this app’s fields are mostly the latter — and it folds three separate platform settings into one "is this prose" switch, covering autocorrect, spelling suggestions and sentence capitalisation. The standard property is kept in step for anyone who reads it. The chat composer is the one field that asks for it.

ReturnKey is a ReturnKeyMode — Auto (submit when single-line, newline when multiline), Newline, or Submit. It is one attribute rather than the separate key-label enum the design sketched, because the label follows from the behaviour: a field that submits asks the OS for a Send key, and one that does not asks for nothing. A Search or Go label can be split out when something needs it.

AutoGrow follows multiline unless authored. Both it and ReturnKey are set explicitly on the chat composer rather than left to their defaults, because whether Unity’s UXML serialiser applies an unauthored attribute (and so overwrites a computed default) was not something this could be tested against — explicit authoring is correct either way.

Selection has to go through SelectAllText/SelectTextRange on the field: textSelection is an interface UI Toolkit hands out directly, so a call on it has nothing this class can intercept.

AutofillHint is not implemented — password-manager AutoFill is still on the list, and nothing in the app has a password field yet.

InputMode/WebInputMode is removed. It duplicates keyboardType + isPassword under a Web-specific name; its two call sites (PromptPresenter, which already sets both) migrate to the standard properties.

Per-platform manual checklist, since none of this is unit-testable: first-tap caret placement, drag-select, long-press Paste, magnifier, dictation, autocorrect bar, password AutoFill, Return = Send with the keyboard staying up, multiline growth up to max-height then internal scroll, blur by tapping elsewhere, blur by the Android back key, keyboard open/close with the field tracking the pill, a popup opening over the field (renderer swap, no stolen touches), rotation, app backgrounding mid-edit, and — on Web — desktop keyboard shortcuts still reaching Unity while a field is on screen but unfocused.