fix(wasm): Focus the hidden input again when its TextBox is tapped on iOS - #25185

GitHub Issue: closes #22258, closes #25183

PR Type:

🐞 Bugfix

What changed? 🚀

By default iOS only shows the soft keyboard for an input that is focused while the user is interacting with the page (-[WKContentView _elementDidFocus:userIsInteracting:...]). A TextBox focused from code at another time, such as the one a dialog opens on, gets no keyboard, and tapping it does not bring one up either: the tap lands on the canvas, and the hidden input, which has focus already, is not focused again.

BrowserInvisibleTextBoxViewExtension.refocus now focuses the hidden input again when a TextBox is tapped while it has focus, and when a tap moves focus to a TextBox the input is handed over to. WebKit treats focus() on the focused element as a refocus (Element::focus calls elementDidRefocus), reports it to the UI process as long as no input view is showing for the element (WebPage::shouldDispatchUpdateAfterFocusingElement) with the user interacting when it is called from inside the tap, and does nothing when the keyboard is showing already.

• The managed side reaches it through ITextBoxNotificationsProviderSingleton.OnFocused, which a TextBox already raises when it takes focus and when it is tapped while focused, synchronously inside the pointer event.
• The input raises no focusin for it, so the trailing-click guard is armed there for a touch or pen tap, as it is for the tap that focuses the input.
• Limited to iOS, by the gate that already keeps the input off-screen there, which also takes an iPad in desktop mode (MacIntel with touch points) for iOS. Elsewhere it returns before touching the input.

RichEditBox, which shares the hidden input but does not raise this notification, is not covered.

An application built from the final head was compared with one built from master on iOS 26.5 in the iPhone 17 simulator (Safari; a simulator, not a physical device), tapped by hand:

• A TextBox focused from code, tapped once: the keyboard comes up with the change. On master it does not, and the focus visual and the caret go away.
• The field of a ContentDialog, focused when the dialog opens, tapped once: the same.
• A focused TextBox whose keyboard was closed with Done, tapped again: the keyboard comes back on both. On iOS 26.5 Done takes the focus away from the input, so this tap is a first tap and does not tell the two apart.

On an Android 15 emulator (Chrome 124), which the change leaves alone, the final head behaves as master: after Back hides the keyboard, a tap on the field brings it up again. An earlier check on an iOS device, on a 6.8 build with a backport of this change, gave the same result for a tap on the focused TextBox. What WebKit does with the refocus is read from its source.

Why this is the fix for #22258

#22258 reports a ContentDialog that opens on a focused TextBox with no keyboard, and asks for the keyboard to open with the dialog. There are two halves to it, and a page can only do something about one of them.

The keyboard does not open with the dialog, and a page cannot make it. By default WebKit starts an input session for an element only when it takes focus while a touch is being dispatched, when another element already holds a session, or when a hardware keyboard is attached. The TextBox of a dialog takes focus once the dialog has loaded, which is after the tap that opened it is over, so iOS accepts the focus and shows no keyboard. That is WebKit's rule for every page that focuses a field from script. It is not something the hidden input gets wrong, and the TextBox cannot take focus any earlier: it is not in the tree until the dialog is.

Tapping the focused field did nothing, which is what left the user stuck. The tap on the field is the gesture iOS is waiting for, but it never reached the input: the only way to a keyboard was to tap another field and come back, as the issue describes. With this change the first tap on the field brings the keyboard up, which is what a web page gets on iOS for a field it focused from script.

One way around the first half was built and dropped. On every tap that leaves no TextBox focused, it focused a hidden read-only input that asks for no keyboard, so that iOS had an input session going which a TextBox focused from code shortly afterwards took over, keyboard included. That focuses an input for taps that have nothing to do with text. Going by WebKit's source it brings up the browser's form accessory bar on an iPhone for each of them, and whether the session is handed over rests on timing inside WebKit that an application has no say in. It would put every tap of every application at risk to save one tap on a field.

Tests

Given_TextBox (new file Given_TextBox.BrowserRefocusOnTap.cs), Skia WASM. The tests make the bridge take the browser for an iOS one and count the calls that focus or blur the hidden input:

• When_Focused_TextBox_Tapped_On_iOS_Then_Input_Focused_Again: a tap on a TextBox that was focused from code focuses the input again without blurring it, and so does a later tap, with the trailing-click guard armed.
• When_Another_TextBox_Tapped_On_iOS_Then_Input_Focused_Again: the same for the tap that moves focus from one TextBox to another.
• When_Focused_TextBox_Clicked_With_Mouse_On_iOS_Then_Next_Click_Left_Alone: a mouse click focuses the input again as well and leaves the guard alone.
• When_Focused_TextBox_Tapped_Off_iOS_Then_Input_Left_Alone: nothing is called off iOS.

The first three fail on master without the change; the last one passes on it. They cover the bridge's side, not WebKit's, which is what the device check is for. Given_TextBox, Given_PasswordBox and Given_RichEditBox pass in full on Skia WASM with the change (1323 tests, none failed). After the review changes, Given_TextBox and Given_PasswordBox were run again on Skia WASM: 200 passed, none failed, and 30 were inconclusive, the clipboard and pointer-hold tests that can't run in that setup.

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