fix(wasm): iPad soft-keyboard focus (dismiss, LostFocus, bring-into-view)

[ajpinedam]

GitHub Issue: Associated with an internal tracking issue (customer-reported).

PR Type:

🐞 Bugfix

What changed? 🚀

Fixes three focus-related bugs specific to the Skia WebAssembly head on touch devices (iPad Safari/Chrome). All three stem from the single shared, invisible <input id="uno-input"> that is positioned over the one <canvas> used for all text entry. None of them affect desktop Skia, WinUI, or the native (non-Skia) heads.

1. Soft keyboard opens on a TextBox tap, then immediately dismisses itself.
Touch browsers synthesize a trailing compatibility mousedown after a tap's focus change; it lands on the non-focusable canvas and its default action blurs the just-focused #uno-input, closing the keyboard. Uno already preventDefaults pointer events, but per the Pointer Events spec that does not suppress the synthesized mouse-compatibility events. Fix: a one-shot, touch/pen-scoped guard that swallows the single trailing canvas mousedown/click following the input's focusin (armed on focusin, disarmed on the next pointerdown). Desktop mouse is unaffected — there mousedown precedes focus, so the guard never arms.

2. LostFocus never fires when the keyboard is dismissed this way.
Focus was driven one-way (managed → native): nothing listened for the browser blurring #uno-input on its own, so FocusManager stayed out of sync and LostFocus never fired. Fix: a blur listener on the input reports genuine, browser-initiated blurs to a new OnNativeBlur export, which calls TextBox.Unfocus() — the same terminal focus-clearing path the iOS and native WASM heads already use. Managed-initiated blurs are suppressed so a focus switch never clears the wrong control.

3. A focused field near the bottom is not scrolled above the keyboard.
The Skia WASM head had no InputPane producer — nothing ever set InputPane.OccludedRect, so the shared bring-into-view path never ran. Fix: a visualViewport listener computes the keyboard occlusion (gated on the invisible input being focused, so browser-chrome resizes don't count) and feeds InputPane.OccludedRect, mirroring the iOS/Android heads. The consuming logic (InputPane.skia.cs → ScrollContentPresenter.Pad + StartBringIntoView) already shipped in the WASM build; this only supplies the missing producer. This also makes InputPane.Showing/Hiding fire on this head, matching the other platforms.

Validation

• Compiles clean: the runtime head and the full SamplesApp.Skia.WebAssembly.Browser app.
• Runtime test Given_InputPane.When_OccludedRect_Set_Then_Focused_TextBox_Scrolled_Into_View passes on Skia Desktop — it exercises the device-independent consumer path (issue 3).
• Manual on-device sample SoftKeyboardFocusTests (GotFocus/LostFocus counters, live OccludedRect readout, bottom field). Issues 1 and 2, and the on-device occlusion computation, reproduce only on a real iPad (not the iOS Simulator or desktop-browser emulation), so final device validation there is still required — this PR is a draft pending that.

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

[unodevops]

🤖 Your WebAssembly Skia Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-23890/wasm-skia-net9/index.html