fix(wasm): Raise Enter once per press in a TextBox - #25174

GitHub Issue: closes #25173

Related: #24502 changes the same handlers of the hidden input. Whichever of the two lands second needs a small rebase, which I will take care of. This branch is rebased on #25804, which changed them too (see below).

PR Type:

🐞 Bugfix

What changed? 🚀

Enter in a TextBox that does not accept returns reaches managed code through up to three DOM events: its keydown (through BrowserKeyboardInputSource), the beforeinput of the line break the browser then sets out to insert (through OnEnterKeyPressed), and its keyup. With a hardware keyboard the first two each raised KeyDown, and since OnEnterKeyPressed raises the release too (#24575) KeyUp came twice as well. One press gave KeyDown, KeyDown, KeyUp, KeyUp.

Each press is now raised once:

• The beforeinput handler leaves a key alone that BrowserKeyboardInputSource raises from its keydown. It does so for a keydown that has the code it tells the key by (Enter or NumpadEnter) and, since fix(textbox): Fix IME and touch editing on Android browsers #25804, which maps a key without a code by its name, for one without a code named Enter. A soft keyboard's Enter whose keydown is unidentified is still raised from the beforeinput.
• The keyup handler does not raise a key the beforeinput handler raised. When BrowserKeyboardInputSource would raise that keyup as Enter's release (it has a code, or none and is named Enter), the handler stops it from reaching the source.
• The keyup the handler raises the key for is kept from BrowserKeyboardInputSource too, which fix(textbox): Fix IME and touch editing on Android browsers #25804 already does on master.

On master, #25804 also brought a double Enter: the keyboard input source raises a soft keyboard's Enter from its code-less keydown named Enter, and the line break that follows raises it again (KeyDown, KeyDown, KeyUp, KeyUp). 53e146e fixes that along with the rest, as When_SoftKeyboard_Enter_Has_No_Code shows.

The presses of Enter that are down are tracked by the code of their key (Enter, NumpadEnter, or none for a soft keyboard's):

• which ones had a keydown seen as Enter's
• which ones the line break raised, release included

A keydown without a code counts as a possible press of Enter unless it names another key (a soft keyboard's Backspace, say).

A press can outlive the hidden input it started on, so its entries are not tied to the input. They last until the keyup of the key, wherever that goes, or until its next keydown.

BrowserKeyboardInputSource now reports the keydown and keyup events that reach the document to the hidden input's code:

• It records the presses of Enter it raises itself.
• It does not raise a release that was already raised with its press.

A press therefore stays a single one in these cases:

• Another key goes down before Enter is released.
• The main and the numpad Enter overlap.
• A handler moves focus off the TextBox before the keyup, which then goes to the document.
• The press starts on another control (or on a TextBox that accepts returns) and is released on a TextBox. That TextBox now gets the release only.

The managed side is unchanged. For a key pressed and released on a TextBox, the change only stops the duplicate presses and releases described above.

The browser and device checks below were made before the rebase on #25804, on the product code of 7360f2a (unchanged up to b2a91d2, the commits after it only add tests and comments), against master as it was in mid-October. They weren't rerun at the rebased head; the replayed DOM events in the tests are.

A trusted Enter press sent through the DevTools protocol (Chrome 154, then Chrome 155 at b2a91d2: Input.dispatchKeyEvent, every keydown, beforeinput and keyup checked to be trusted) to a TextBox gave KeyDown, KeyDown, KeyUp, KeyUp on that master and KeyDown, KeyUp with the change, and the same went for the Enter of the numeric keypad and for a PasswordBox. A held Enter gave a KeyDown for each repeat and one KeyUp. The same press without a code, which is how Chrome on Android sends the action key of the soft keyboard, gave one KeyDown and one KeyUp for Enter on both, between the KeyDown and the KeyUp of an unidentified key. Since #25804, the keyboard input source names that press Enter, and with the replayed events current master gives two of each (see above).

An application built from that code was compared with one built from that master on devices:

• Android 15 emulator (Chrome 124, Gboard, real taps): Gboard's Enter gives one KeyDown and one KeyUp for Enter on both. The emulator's hardware Enter gives one of each with the change and two of each on master.
• iOS 26.5 in the iPhone 17 simulator (Safari; a simulator, not a physical device), tapped by hand: the Return key of the soft keyboard gives one KeyDown and one KeyUp for Enter on both, in a TextBox that does not accept returns. In one that accepts returns, both give one of each and one new line per press.

An earlier backport of this change on a 6.8 build was checked on Android and iOS devices (Next and Done) and behaved as it should.

Tests

Given_TextBox (new file Given_TextBox.BrowserEnterKey.cs), Skia WASM, replaying the DOM events on the hidden input:

• When_Hardware_Keyboard_Enter_Pressed: keydown, beforeinput, keyup with a code.
• When_Hardware_Keyboard_Enter_Moves_Focus_On_Release: the same press with a KeyUp handler that moves focus to the next of three fields; it ends on the second.
• When_Hardware_Keyboard_Enter_Is_Named_On_Release_Only: a keydown reported as the IME's, then a keyup of Enter with a code.
• When_Hardware_Keyboard_Enter_Is_Named_On_Release_After_Line_Break: the same with a beforeinput in between.
• When_SoftKeyboard_Enter_Is_Named_On_Release_After_Line_Break: an unidentified keydown, a beforeinput, then a keyup named Enter without a code.
• When_Another_Key_Goes_Down_Before_Enter_Named_On_Release_After_Line_Break_Is_Released: a keydown reported as the IME's and its beforeinput, then another key going down (one the IME takes, and a modifier) before the keyup of Enter; Enter is still raised once.
• When_Hardware_Keyboard_Enter_Follows_Line_Break_Without_Key_Events: a line break on its own, another key typed, then a press of Enter in both hardware keyboard shapes; each Enter is raised.
• When_Enter_Named_On_Release_After_Line_Break_Moves_Focus_Off_The_TextBox: the KeyDown of a line-break-raised Enter moves focus to a button, so the keyup goes to the document, or never comes. The button gets no release for it, and the next press of the key is raised in full. A third row does this for a soft keyboard, whose keyup has no code.
• When_Enter_And_Numpad_Enter_Presses_Overlap: both Enter keys down at once; two presses are raised, not three.
• When_Enter_Named_On_Release_Only_Follows_Hardware_Keyboard_Enter_That_Moved_Focus: a hardware Enter moves focus off the TextBox and is released on the document; an Enter the next TextBox only learns of by its keyup (a soft keyboard's, and one with a code) is raised.
• When_Hardware_Keyboard_Enter_Pressed_On_Another_Control_Is_Released_On_The_TextBox: the keydown goes to the document and moves focus to the TextBox, which gets the line break and the keyup; it sees the release only.
• When_Hardware_Keyboard_Enter_Is_Held: the repeats of a held Enter raise KeyDown each, and one KeyUp.
• When_Hardware_Keyboard_Enter_Release_Is_Lost: a press of Enter whose keyup never comes, then another press: one named on its keydown followed by one reported as the IME's, and the other way around, where the line break raised the first press with its release. The second press is raised in full.
• When_SoftKeyboard_Enter_Has_No_Code_And_TextBox_Accepts_Returns: a press of Enter without a code in a TextBox that accepts returns, which handles the key itself, raises it once.
• When_SoftKeyboard_Key_Goes_Down_Before_Enter_Named_On_Release_After_Line_Break_Is_Released: an unidentified keydown and its line break, then a soft keyboard's Backspace (no code) going down before the keyup named Enter; Enter is still raised once.
• When_SoftKeyboard_Enter_Has_No_Code, When_SoftKeyboard_Enter_Is_Named_On_Release_Only, When_SoftKeyboard_Enter_Is_Never_Named, When_SoftKeyboard_Line_Break_Comes_Without_Key_Events, When_SoftKeyboard_Line_Break_Follows_Hardware_Keyboard_Enter, When_SoftKeyboard_Line_Break_Follows_Hardware_Keyboard_Enter_That_Moved_Focus: the soft keyboard shapes, press after press and after a hardware keyboard's.

What fails without which part of the change:

• On master at 46ea872 (its TypeScript, with this branch's test file except When_SoftKeyboard_Enter_Has_No_Code_And_TextBox_Accepts_Returns), 18 of the 26 cases fail. The 8 that pass are When_Hardware_Keyboard_Enter_Is_Named_On_Release_Only (fix(textbox): Fix IME and touch editing on Android browsers #25804 now keeps that keyup from the keyboard input source), the row of Moves_Focus_Off_The_TextBox whose release is lost, the Process row of When_Hardware_Keyboard_Enter_Follows_Line_Break_Without_Key_Events, When_SoftKeyboard_Enter_Is_Named_On_Release_Only, When_SoftKeyboard_Enter_Is_Never_Named and the three When_SoftKeyboard_Line_Break_* tests. When_SoftKeyboard_Enter_Has_No_Code passed on master before fix(textbox): Fix IME and touch editing on Android browsers #25804 and fails on it now.
• On this branch rebased on fix(textbox): Fix IME and touch editing on Android browsers #25804, before 53e146e, When_SoftKeyboard_Enter_Has_No_Code and When_SoftKeyboard_Enter_Is_Named_On_Release_After_Line_Break failed: the beforeinput raised again a press the keyboard input source had raised from its keydown, and the source raised a second release for a keyup named Enter after a line break.
• Without the document keyup check of 53e146e (a code-less keyup named Enter), the soft keyboard row of Moves_Focus_Off_The_TextBox fails: the button gets a second release.
• Without a9e04bf, When_SoftKeyboard_Key_Goes_Down_Before_Enter_Named_On_Release_After_Line_Break_Is_Released fails: the Backspace drops what the line break recorded, and the keyup raises Enter again.
• Checked before the rebase: When_Another_Key_Goes_Down_Before_Enter_Named_On_Release_After_Line_Break_Is_Released fails when every keydown clears what the line break recorded.
• Checked before the rebase: When_Hardware_Keyboard_Enter_Follows_Line_Break_Without_Key_Events fails when a keydown that has the code of Enter is taken for another key.
• Checked before the rebase: When_Hardware_Keyboard_Enter_Release_Is_Lost fails, in both rows, when no keydown clears what the earlier press left (the input's keydown handler does, and onKeyDownAtDocument does for the line break's entry of a coded keydown).
• Checked before the rebase: the four tests from Moves_Focus_Off_The_TextBox to Is_Released_On_The_TextBox fail with the state tied to the input, as it was before the second review round.

Each test clears the content it loaded.

Runs: all on Skia WASM in Chrome, with the DOM events replayed (synthetic, untrusted events).

• At a9e04bf, rebased on master at 46ea872: the 27 cases of this file pass, and Given_TextBox, Given_PasswordBox, Given_BrowserKeyboardInputSource and Given_AccessibleTextBox give 384 passed, 30 inconclusive (clipboard and pointer-hold tests) and 1 failed, Given_TextBox.When_Touch_LongPress_Drag_Release_Does_Not_Open_Flyout_iOS, which fails the same way on a Skia desktop build of master on this machine.
• At b2a91d2, before the rebase: the 24 cases of this file (19 test methods, 5 of them with two data rows) passed, and Given_TextBox and Given_PasswordBox passed (219 passed, none failed, 30 inconclusive: the clipboard and pointer-hold tests can't run in that setup).
• Given_TextBox, Given_PasswordBox and Given_Button passed in the second review round (261 tests, none failed).
• Given_TextBox, Given_PasswordBox and Given_RichEditBox passed in full before the review changes (1326 tests).

Known limitations

• An Enter that commits an IME composition is still raised as Enter, from its keyup, as before. That shape was only replayed as DOM events, not tried with an IME.
• A line-break-raised press that is held raises a KeyDown and a KeyUp for each repeat.
• A soft keyboard's line break that comes without any key event is not raised in one narrow case: a hardware Enter pressed on another control lost its keyup (the page lost focus), and a TextBox was focused next. Any keydown clears that state.
• Before fix(textbox): Fix IME and touch editing on Android browsers #25804, in a TextBox that accepts returns, the Enter of an Android soft keyboard (Gboard) raised no Enter key events, only a KeyDown and a KeyUp of an unidentified key, because its keydown has no code. fix(textbox): Fix IME and touch editing on Android browsers #25804 maps such a key by its name, and a press named Enter now raises Enter there (When_SoftKeyboard_Enter_Has_No_Code_And_TextBox_Accepts_Returns). I haven't rechecked it with Gboard itself.
• A press of Enter whose keyup never comes stays recorded until the next keydown of the key. A keyup of the key that comes before that, with no keydown of its own, is taken for the lost one's, and no press is raised for it.

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!)