fix(ime): Raise composition events after their text on browser soft keyboards - #26434

GitHub Issue: closes #26432

PR Type:

🐞 Bugfix

What changed? 🚀

This builds on #25804's IME design (the hidden input is the source of truth for composition text, and the TextBox follows it with textAlreadyApplied) and fixes what is left of the bugs #24502 fixed under its earlier design. It supersedes #24502, which I'll close. #25804's own body lists the first one as a known follow-up.

Each fix is its own commit, with its tests:

1. TextCompositionChanged is raised once its text is in Text (TextBox and RichEditBox, WebAssembly and Skia Android)
The platform applies the composition itself and reports it before the text sync that follows it (the browser's input event, Android's EndBatchEdit). The event was raised on that report, so its range pointed into text that wasn't there yet: a handler reading Text.Substring(e.StartIndex, e.Length) threw, and one moving focus sent the rest of the keystroke to the next TextBox. The event now waits for the sync, after TextChanging, as for text the TextBox applies itself. RichEditBox holds its Composition and ConversionTargetChanged automation events with it. An update whose text the control refused, and so isn't in Text, isn't raised. This changes the order of the events on every platform-applied update, so on Skia Android too, not only on WebAssembly.
On WebAssembly, a TextCompositionStarted or TextCompositionEnded handler that moves focus no longer gets the browser's text synced into the TextBox that took focus.
The ranges of TextCompositionChanged and of a composition ending without a commit (cancel, coercion, external change) are clamped to the text. A commit's TextCompositionEnded keeps the committed text's own range, since Skia Android raises it before syncing that text (the point morning4coffe-dev made on #24502).
Skia Android now passes where its composing region starts, as the browser does, so a composition opened on an existing word is placed there.
Tests: When_IME_Platform_Applied_Composition_Changed_After_Its_Text (TextBox) and When_Platform_Applied_Composition_Changed_After_Its_Text (RichEditBox), which replay Android's order with a fake extension on every Skia target; on WebAssembly When_Browser_Ime_Changed_Handler_Reads_Composition, When_Browser_Ime_Composition_Repeats_Existing_Character, When_Browser_Ime_Composition_Extends_Existing_Text, When_Browser_Ime_Caret_Moved_Inside_Preedit_Repeating_Text, When_Browser_Ime_Composition_Preedit_Emptied, When_Browser_Ime_Composition_Coerced_Shorter_Than_Its_Start, When_Browser_Ime_Changed_Handler_Moves_Focus, When_Browser_Ime_Started_Handler_Moves_Focus, When_Browser_Ime_Ended_Handler_Moves_Focus (each with a single-line and a multi-line target), two WebKit commit orders this already fixes (When_Browser_Ime_WebKit_Commit_Equal_To_Preedit_Ends_At_Once, When_Browser_Ime_WebKit_Preedit_Removed_Before_Cancel) and Given_RichEditBox.When_Wasm_Composition_Reopened_On_Existing_Text_Changed_Sees_The_Preedit.

2. A composition ends when the hidden input is replaced or removed (WebAssembly)
The browser's compositionend for a replaced or removed input is ignored on purpose, so when the same TextBox was re-entered with another focus state (a tap after keyboard focus) or accessibility detached the input while the TextBox kept focus, IsComposing stayed true and TextCompositionEnded never came. focus() and detachCore() now end it.
Tests: When_Browser_Ime_Same_TextBox_Refocused_During_Composition, When_Browser_Ime_Input_Detached_During_Composition.

3. A composition edit the control refuses, or keeps at another length, is written back at once (TextBox and RichEditBox, WebAssembly and Skia Android)
#25804 reconciles a control's edit made during a composition when the composition ends. Until then the refused text stayed in the hidden input, and the keyboard kept composing on it: typing a, an x a BeforeTextChanging handler rejects, then b left Text at a. Gboard composes every Latin word, so with MaxLength the letters typed past the limit stayed in the input for the whole word: the keyboard built its suggestions on them, and Backspace deleted them before it reached the TextBox's text.
Now, when the control keeps text of another length than the input's (MaxLength, a TextChanging length limit, a RichEditBox cutting the edit to its text limit), or refuses a change of the input's text and keeps its own previous text (BeforeTextChanging, read-only), its text goes back to the input at once and the composition ends, for the control too, with the caret pushed back to the input. The keyboard then builds its next keystrokes and suggestions on the text the control kept. Kana typed past a limit is cut at the limit rather than converted later (MaxLength="2": にほん leaves にほ). A change that keeps the length, such as an upper-case TextChanging filter on a TextBox or CharacterCasing on a RichEditBox, keeps #25804's reconciliation at the composition's end, so an IME can still convert it; the input reports its previous value with each edit, so the same text reported again while such a filter keeps the two texts apart (a caret move inside the preedit) isn't taken for a refusal.
On Skia Android, EndBatchEdit left such an edit in the native editable, since a refusal raises no text change to write back; the editable now takes the host's text at once, as one change, and loses its composing region, which ends the composition there too. A refused sync there also left the host's caret where the IME put it in the refused text, so the next key landed one place late; it now stays where the edit started.
This takes three commits: the first writes back a BeforeTextChanging or read-only refusal and keeps #25804's reconciliation for everything else; the second extends the write-back to MaxLength and length-changing edits, with RichEditBox, on WebAssembly; the third does the same on Skia Android.
Tests: When_Browser_Ime_Composition_Rejected_By_BeforeTextChanging, When_Browser_Ime_Same_Length_Replacement_Is_Refused, When_Browser_Ime_Composes_Word_Past_MaxLength_Then_Input_Keeps_The_Limit (MaxLength="3", "abcd" composed: the input holds "abc" right after the update, and one Backspace deletes the "c"), When_Browser_Ime_Kana_Composes_Past_MaxLength, When_Browser_Ime_Kana_Composes_Past_TextChanging_Limit, When_Browser_Ime_Filtered_Composition_Reported_Again_Stays_Open, Given_RichEditBox.When_Wasm_Composition_Past_MaxLength_Is_Written_Back, When_Wasm_Composition_Past_MaxLength_In_The_Middle_Keeps_The_Caret and When_Wasm_Composition_With_Upper_Casing_Stays_Open; on every Skia target When_IME_Platform_Sync_Refused_Then_Caret_Stays, and When_Native_Text_Is_Compared_To_The_Kept_Text, a table of the rule's cases (line breaks, casing, length, same-length refusal); When_Browser_Ime_Composes_Past_MaxLength and When_Browser_Ime_Composition_Coerced_Shorter_Than_Its_Start now check the input right after the update; #25804's When_Browser_Ime_Composes_With_TextChanging_Filter still passes unchanged.
I checked the MaxLength write-back by hand with Gboard in Chrome on an Android phone, on a 6.8 build.

4. The hidden input is read-only for a read-only TextBox (WebAssembly)
It stayed editable, so a mobile browser opened the soft keyboard and let the user type into it until each edit was reverted; WinUI doesn't show the touch keyboard for a read-only TextBox. The input now gets readOnly and follows IsReadOnly. A read-only RichEditBox already suppressed the soft keyboard (inputmode="none"); it gets readOnly too, for consistency.
Mobile browsers show or hide the keyboard when an element takes focus, not when readOnly flips on the focused one. So focus moving between a read-only and an editable TextBox now focuses a new input instead of reusing the focused one, and IsReadOnly changing on the focused TextBox enters a new input as focus does (except during a composition, which keeps its input).
A read-only input still takes focus, a caret and a selection, and still gets key events and copy; the browser only refuses edits to it. I checked that in Chrome 157 with trusted CDP input on a plain read-only input: focus, ArrowLeft and Shift+ArrowLeft move the caret and the selection, keydown/keyup and copy fire, and typing fires beforeinput but leaves the value unchanged. The runtime test uses synthetic key events, so it shows that the TextBox still handles the keys and the input follows its selection, not native copy.
#25804's When_Browser_Input_Edits_Read_Only_TextBox said the input stays editable under a read-only TextBox; it now checks the input is read-only, and still that an edit reaching it anyway is refused.
Re-applying the properties when IsReadOnly changes also re-applies the keyboard type, autocorrect and accessory view on Apple UIKit, which is harmless.
Tests: When_Browser_Read_Only_TextBox_Keeps_Keyboard_And_Selection, When_Browser_Focus_Moves_From_Read_Only_TextBox, When_Browser_Read_Only_Toggled_On_Focused_TextBox, When_Browser_Input_Edits_Read_Only_TextBox (updated), Given_RichEditBox.When_Wasm_Read_Only_Hidden_Input_Follows_IsReadOnly, and When_Browser_Ime_TextBox_Made_Read_Only_During_Composition (the composition still ends; that part already worked on master).

5. The caret is restored at once after a refused input (WebAssembly)
After the TextBox refused a plain edit, the caret went back to where the edit started a dispatcher tick later, so a key typed in between landed where the refused edit left it ("abc" with the caret after "a": a refused "x" then "y" gave "abyc"). It is now restored while the refused edit is applied, and the restore a tick later is skipped on this path.
Test: When_Browser_Input_Refused_Then_Next_Key_Follows_At_Once.

6. More soft keyboard sequences as regression guards (test only)
#24502's soft keyboard tests that already pass on master and have no equivalent there, adapted to master's helpers: When_Browser_Soft_Keyboard_Backspace_Has_No_Code_In_PasswordBox, When_Browser_Ime_Caret_Moved_During_Composition, When_Browser_Ime_Composition_Ends_On_Replaced_Input, When_Browser_Ime_Multiline_Line_Break_During_Composition, When_Browser_Multiline_Selection_Follows_Native, When_Browser_Ime_Text_Set_By_TextCompositionEnded_Handler, When_Browser_Ime_Text_Cleared_During_Composition.

Not in this PR: the rest of #24502's WebKit/iOS commit ordering, which I'm proposing separately in #26435 (stacked on this one).

Validation

• Runtime, Skia WebAssembly (Chrome 157, the browser's event sequences replayed on the hidden input): Given_TextBox, Given_RichEditBox, Given_PasswordBox, Given_BrowserKeyboardInputSource, Given_AccessibleTextBox and Given_ImeSessionCoordinator*: 1391 of 1422 pass, 30 inconclusive. The one failure, When_Touch_LongPress_Drag_Release_Does_Not_Open_Flyout_iOS, fails the same way without these changes.
• Runtime, Skia desktop (Windows): Given_TextBox, Given_RichEditBox, Given_PasswordBox and Given_ImeSessionCoordinator*: 1420 of 1422 pass, one inconclusive; the one failure is the same iOS touch test.
• Compile: Uno.UI.Runtime.Android (net10.0-android).
• Tests fail before the fix: on master's product code, every new or changed fix test here fails (on WebAssembly, and the three shared-code tests on desktop too), except these: the single-line rows of When_Browser_Ime_Started_Handler_Moves_Focus/When_Browser_Ime_Ended_Handler_Moves_Focus, where the reused input is emptied for the newly focused TextBox before the stale sync, so only the multi-line rows (a new textarea) show the bug; and When_Browser_Ime_Filtered_Composition_Reported_Again_Stays_Open and When_Wasm_Composition_With_Upper_Casing_Stays_Open, which pass on master too, as they check that fix 3 keeps a filtered composition open as master does. When_Native_Text_Is_Compared_To_The_Kept_Text calls the new rule directly, so it doesn't compile on master; the mutations below cover its rows. The 7 regression guards pass on master, and so does When_Browser_Ime_TextBox_Made_Read_Only_During_Composition without its readOnly checks. On the first commit of fix 3 alone, When_Browser_Ime_Composes_Word_Past_MaxLength_Then_Input_Keeps_The_Limit and both When_Browser_Ime_Kana_Composes_* fail; with every difference written back, When_Browser_Ime_Composes_With_TextChanging_Filter fails, and with only refusals written back, When_Browser_Ime_Composition_Coerced_Shorter_Than_Its_Start fails; without the RichEditBox change, When_Wasm_Composition_Past_MaxLength_Is_Written_Back fails, with every RichEditBox difference written back When_Wasm_Composition_With_Upper_Casing_Stays_Open fails, and without the caret push after its write-back When_Wasm_Composition_Past_MaxLength_In_The_Middle_Keeps_The_Caret fails; with the input's previous value ignored, When_Browser_Ime_Filtered_Composition_Reported_Again_Stays_Open fails, and with only length changes written back, When_Browser_Ime_Same_Length_Replacement_Is_Refused fails, each with the matching rows of When_Native_Text_Is_Compared_To_The_Kept_Text; without the caret restore, When_IME_Platform_Sync_Refused_Then_Caret_Stays fails; with the read-only check removed from the input reuse, or the re-entry on an IsReadOnly change, When_Browser_Focus_Moves_From_Read_Only_TextBox and When_Browser_Read_Only_Toggled_On_Focused_TextBox fail.

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
• 👀 Reviewed 2 other open pull requests (optional but appreciated!)