fix(textbox): Limit only user input to MaxLength - #26005

GitHub Issue: closes #25997

PR Type:

🐞 Bugfix

What changed? 🚀

Before: a TextBox with MaxLength refused any new Text longer than MaxLength, even one set from code, a Binding or x:Bind, and kept its previous text. An editor that reuses one TextBox for several items could show the previous item's text for an item with a long value, and the next edit wrote that text into the current item. Once the text was longer than MaxLength, the user also couldn't delete characters one by one, and Undo couldn't put the text back. PasswordBox.Password behaved the same way.

After: MaxLength limits only user input, as on WinUI. The PR has three commits:

1. fix(textbox): Limit only user input to MaxLength

• Text set from code is kept whole and raises the usual events: Text, bindings, SelectedText, PasswordBox.Password, and text an app sets inside a TextChanging or SelectionChanged handler while the user types.
• User input that would leave the text longer than MaxLength is refused, with no BeforeTextChanging, as before. A paste still inserts only what fits.
• An edit that only deletes text goes in, even while the text is still longer than MaxLength. Backspace from the browser or the Android keyboard in multi-line text works too.
• Undo and Redo aren't limited: they put back text the TextBox already held, as on WinUI.
• UI Automation: setting a value through the TextBox or PasswordBox automation peer refuses a value longer than MaxLength and keeps the text, as WinUI's UI Automation does; a value that fits is applied like text set from code. On the Win32 host, the error reaches the client as UIA_E_INVALIDOPERATION, where WinUI returns E_FAIL.
• WebAssembly semantic text box: typing on a physical keyboard already went through key events. What changes is input that only the browser sees: phone keyboards, IME, dictation and autocorrect. It now takes the user-input path, so MaxLength applies to it and it's reported as user input (an AutoSuggestBox sees UserInput). When the TextBox refuses such input, the semantic element shows the TextBox's text again. A read-only TextBox used to throw there, and a disabled one accepted the input; both now refuse it.
• macOS accessibility: the same rule as on WinUI. Setting the whole value (setAccessibilityValue) is like UI Automation's set-value, so a value longer than MaxLength is refused. Replacing the selected text (setAccessibilitySelectedText, which dictation uses) is user input, like typing. When the TextBox refuses either, the native element shows its text again; a PasswordBox gets no text there.
• Android autofill is cut to fit MaxLength, as Android's own text fields do, and goes in as user input. A read-only or disabled box ignores it.
• Native text views (the browser's hidden input, the Android and iOS keyboards): when the TextBox refuses their text, it keeps its own caret instead of taking the native one. In the browser, the input path from fix(textbox): Fix IME and touch editing on Android browsers #25804 now selects only when the edit is applied, so the selection doesn't go to the refused caret and back, and raises no SelectionChanged.
• iOS: the keyboard's Backspace is let through in over-long text; before, the native input refused it. A PasswordBox whose password is longer than MaxLength keeps it when it gets focus: the native field puts its text back then, and that is no longer refused.
• Docs: a new Uno Platform 7.1 section in the migration notes describes the change. 7.0 has branched and master is on 7.1, so the 7.0 guide stays as it is: it describes what 7.0 does.

2. fix(textbox): Record undo steps only once applied

• A deletion (Backspace, Delete, Ctrl+Backspace, Ctrl+Delete) or a spelling suggestion that MaxLength or a BeforeTextChanging handler refuses no longer leaves an undo step. Before, Redo could then apply a refused suggestion past MaxLength.
• Typed keys that MaxLength or a handler all refuse no longer become an empty undo step that clears Redo, as on WinUI.
• Ctrl+Backspace is one undo step. Before, it was recorded twice (once while working out whether the key is handled), so the first Undo did nothing visible.
• Redo while a typing run is open no longer throws ArgumentOutOfRangeException. When there is something to redo, the run is recorded first, which ends what Redo could put back, as typing does on WinUI. With nothing to redo, Redo leaves the typing run open, as before.
• A handler that throws during a deletion, or calls Undo() from KeyDown, no longer leaves a step behind for the next edit.
• A handler that throws during a spelling suggestion no longer stops text set from code from clearing the undo history afterwards. An Undo() that a TextChanging handler runs in the middle of a deletion or a paste no longer makes that edit clear the history.

3. fix(textbox): Keep IME ranges on the applied text

• When MaxLength or a BeforeTextChanging handler refuses an IME composition update, the composition keeps its range. Before a composition has put any text in, it has no text of its own: emptying, cancelling or committing an empty composition no longer deletes the selection it was going to replace, and the composition events report no length. Before, a refused first update followed by a cancel deleted the selection, also at exactly MaxLength.
• A refused commit reports the range of the composition text that is really there.
• A partial commit whose committed part fits on its own keeps that part when the rest doesn't fit.
• The browser and Android apply composition text themselves and report each update before syncing its text, so a refused update has already been reported. The range now goes back to the text that is really there: TextCompositionChanged reports it a second time, and TextCompositionEnded reports that range instead of the length of the refused text.

Which input counts as user input: typing and deleting, paste, input methods, spelling suggestions, native text views (the browser's hidden input, the Android and iOS keyboards), the WebAssembly semantic text box, macOS selected-text replacement, and autofill. UI Automation's set-value and macOS's set-value aren't user input: WinUI refuses an over-long value there, and Uno now does too. The WebAssembly semantic text box differs from them on purpose: it receives the browser's input events, which are the user's own keystrokes, IME and dictation, so it follows the typing rule. The WebAssembly, macOS and iOS changes belong here because these paths used to rely on Text refusing long values: without them, phone-keyboard input on WebAssembly would go past MaxLength, and iOS would block Backspace in text that can now be longer than MaxLength.

The check now runs on the user-input path instead of in the Text coercion, so the coercion no longer needs to tell input from code. One line-break helper serves both, so the check compares the text as the coercion will store it.

Cost: for text within MaxLength, or with no MaxLength, the check returns at once. Only when a user edit would leave the text longer than MaxLength does it normalize the new text's line breaks and compare it with the old text once. Multi-line text with no \n now skips the line-break pass of the coercion, which used to copy it every time.

Not changed here:

• On WinUI, CanRedo is false as soon as typing starts after an Undo; Uno still reports true until the typing run ends.
• Pastes and cuts: a separate PR builds on this one.

Intentional difference from WinUI: a cancelled edit keeps the undo history

When a BeforeTextChanging handler cancels an edit, WinUI clears the whole undo history, both Undo and Redo. I measured this for a cancelled Backspace, typing, paste and cut. Uno keeps the history, as it does today; the cancelled edit just adds no undo step. A MaxLength refusal keeps the history on both.

I left this as it is because:

• Clearing hurts users. Cancelling in BeforeTextChanging is the usual way to filter input. In a digits-only box, a user who types 12345 and hits a letter by accident could no longer undo any of it.
• WinUI's reason doesn't apply to Uno. On WinUI, RichEdit has already changed the text when BeforeTextChanging is raised, so WinUI sets the old text back and clears the undo stack; a comment in TextBox.cpp describes this. Uno raises the event before changing anything, so it has nothing to set back.
• Nothing changes for apps. Uno doesn't clear the history on a cancel today either.

WinUI does come out ahead in one edge case: a handler that refuses an Undo or Redo. Uno moves its place in the history before it applies the step and doesn't move back when the step is cancelled, so the step is used up and the next Undo goes back two steps. Nothing is corrupted, because each step restores its full recorded text. This PR doesn't change that. From its source, WinUI clears the history here too, but I didn't measure this case. Moving the place only once the step is applied would fix it without clearing anything.

If you'd prefer to match WinUI and clear the history on a cancelled edit, I can do that in a follow-up PR.

Validation:

• Base: current master at 09b5f7a, which includes fix(textbox): Fix IME and touch editing on Android browsers #25804. Its browser input and composition tests still pass, among them the ones that rely on input past MaxLength being refused during a composition.
• WinUI: the expected values come from a WinUI 3 app (Windows App SDK 1.8) that drives a TextBox through its own APIs, called the WinUI recording app in the tests. It set text from code, typed through key messages posted to its own window, and set values through UI Automation from a second process. Values that can't be recorded on WinUI are marked in the tests: the native-view, input-method, autofill, accessibility-input, browser and WebAssembly semantic-input cases, and Shift and Ctrl key combinations.
• New tests: Given_TextBox_MaxLength, IME and browser-input tests in Given_TextBox, and semantic-input tests in Given_AccessibleTextBox.
• Skia Desktop (Windows, Win32 host), each commit against the one before it (on 445304d, four commits earlier, none of them about text input):
  • commit 1: 18 of the 28 desktop cases that build against the old code fail there; 7 more call methods the old code doesn't have, and 1 runs only in the browser. All 35 desktop cases pass after it.
  • commit 2: 14 of its 16 new cases fail before it; the other two pass before and after it: a cancelled text set from code inside a deletion (commit 1's rule) and Redo with nothing to redo. For that run, ReplaceWithSuggestion was made internal so the tests could call it. All 51 Given_TextBox_MaxLength desktop cases pass after it.
  • commit 3: its 14 new cases fail before it; all 34 IME cases pass after it.
  • regression, with the paste PR on top: Given_TextBox*, Given_PasswordBox, Given_ImeSessionCoordinator*, Given_AccessibleTextBox, Given_RichEditBox* and Given_BrowserKeyboardInputSource, 1382 cases, 0 failures, without the clipboard tests.
  • the 142 tests (147 cases) in those classes that use the system clipboard, which the 1382 leave out, ran on their own, in a separate window station with its own clipboard: 140 cases pass, 5 are skipped and 1 is inconclusive on this platform, and When_Touch_LongPress_Drag_Release_Does_Not_Open_Flyout_iOS fails, the same way as on master without these changes.
• WebAssembly (headless Chrome): against the old code, 37 of 114 cases fail, among them the semantic deletions, the disabled TextBox, and deleting from over-long text and keeping the selection in the hidden input (the tests that call methods the old code doesn't have were left out). Against commit 2, the 2 browser tests of commit 3's composition ranges fail. At the head of this PR, the MaxLength, IME, browser-input and Given_AccessibleTextBox tests pass, with fix(textbox): Fix IME and touch editing on Android browsers #25804's Given_RichEditBox, Given_ImeSessionCoordinator* and Given_BrowserKeyboardInputSource tests: 220 cases, 1 skipped (mobile only). With the paste PR on top, 272 cases pass, the paste tests included. The composition tests replay Chromium's event order, as fix(textbox): Fix IME and touch editing on Android browsers #25804's do; no real IME or phone keyboard was run.
• Android, iOS and macOS runtimes: on this branch, compiled, not run. The macOS native change (a flag that tells a value set from a selected-text replacement) needs the native library rebuilt on a Mac.
• iOS 27 simulator, on the 6.8 port of this PR: a test app sent key input to the native text views. Backspace in over-long text works in single-line and multi-line boxes, typing past MaxLength is refused, and a PasswordBox keeps an over-long password when it gets focus.

PR Checklist ✅

• 🧪 Added Runtime tests, UI tests, or a manual test sample (for bug fixes / features, if applicable)
• 📚 Docs have been added/updated following the documentation template (for bug fixes / features)
• 🖼️ Validated PR Screenshots Compare Test Run results.
• ❗ Contains NO breaking changes (no API changes; there is a behavior change, below)
• 👀 Reviewed 2 other open pull requests (optional but appreciated!)

Behavior change (described in the new migration entry): a value set from code that's longer than MaxLength is now kept whole, as on WinUI. Apps that relied on MaxLength to refuse such values should check the length themselves before setting them. UI Automation now refuses an over-long value with an error instead of ignoring it.