fix(input): Raise Tapped and RightTapped after PointerReleased bubbles (backport #25818) - #25976

GitHub Issue: closes unoplatform/kahua-private#559

PR Type:

🐞 Bugfix

What changed? 🚀

On Skia heads (managed pointers), Tapped and RightTapped were raised while PointerReleased was still bubbling to the ancestors of the tapped element. WinUI raises them only once PointerReleased has reached the root (CInputServices::RaiseDelayedPointerUpEvent).

That broke a common case: an element inside a ScrollViewer whose Tapped handler opens a flyout or moves the focus, while the focus is outside the ScrollViewer. The ScrollViewer handled the release after the flyout took the focus, so it took the focus back for its first TextBox, and that TextBox scrolled itself into view on its late GotFocus. On an Android tablet the page jumped to the top and the soft keyboard flashed.

Gesture order (Skia, managed pointers)

• Tapped and RightTapped, and the ContextRequested that follows RightTapped, are raised once PointerReleased has bubbled to the root, like WinUI. They're still raised before the captures are released (PointerCaptureLost), and an ancestor isn't tapped twice.
• DoubleTapped is unchanged: like in WinUI, it's raised on the second press, when no release is in progress.
• An exception in a deferred gesture handler is logged, like one in a PointerReleased handler, and the release still completes.

TextBox and PasswordBox

• A TextBox or PasswordBox whose GotFocus is raised after the focus already moved on no longer brings itself into view. RichEditBox already ignores such a GotFocus, as WinUI's TextBoxBase::OnGotFocus does.
• Like in WinUI, the ScrollViewer still focuses its first text input for an instant during the release. The platform text input is now started only once the pointer release has completed, and not at all if the focus has moved away by then. This covers the soft keyboard on Android, the hidden <input> on WebAssembly and the IME session. It removes the keyboard flash on Android, and on the web the hidden input's focus and blur, which made Chrome's autofill bar flicker.
• Tapping an already-focused TextBox notifies the platform again, to re-show a soft keyboard the user hid. That notification is deferred the same way.
• The deferred start still runs inside the same browser event, so iOS Safari still opens the keyboard on a direct tap.

This builds on the fix-ready report, patches and runtime tests attached to the issue. The gesture deferral is reworked to live on the InputManager, per pointer release, and extended to the platform text input.

Validation

• Runtime, Skia Desktop (macOS): Given_UIElement_GestureEventOrder, Given_TextBox and Given_PasswordBox: 311 passed, 8 skipped, 2 inconclusive, 2 failed. The 2 failures (When_Multiline_Pointer_Tap, When_Pointer_RightClick_Selection, caret off by one) fail the same way on the base commit on this machine.
• Runtime, Skia WebAssembly (headless Chrome): Given_UIElement_GestureEventOrder and the TextBox family (Given_TextBox, Given_PasswordBox, Given_ImeSessionCoordinator, Given_AutoSuggestBox, Given_NumberBox): 312 passed, 0 failed, 65 skipped (other platforms). This ran before the re-show deferral was added.
• Tests fail before the fix:
  • Given_UIElement_GestureEventOrder, run on the base commit ab14387c90 with only the test file added: 8 of 13 cases fail. These are Tapped raised by an ancestor of the hit element (mouse and touch), Tapped before PointerCaptureLost (both rows), RightTapped by mouse and by touch hold, and the ScrollViewer focus case (mouse and touch). The 5 that pass guard behavior the base already had: Tapped raised by the hit element itself, which was already raised after the bubble, the two "not raised twice" tests, and the throwing ContextRequested handler.
  • The text-input tests were run against a build with the deferral narrowed back to PointerReleased and the browser input started on focus. The 3 cases expected to fail did fail: the PointerExited test, and the ScrollViewer test for both TextBox and PasswordBox.
  • The re-show test fails without its fix when the focus moves away: the platform is notified twice.
• Real devices, with a manual repro page (not included):
  • Galaxy Tab A8, Chrome: the flyout keeps the focus, the page doesn't scroll, and the hidden input is never focused. A direct tap on a TextBox still opens the keyboard.
  • iPad Pro, iPadOS 26.6.1, Safari: same result. The screen was recorded and checked frame by frame: the keyboard opens on a direct tap and never flashes when the flyout opens or the focus moves.
  • Galaxy Tab A8, Skia Android (Release): the keyboard flashed in 3 of 4 taps before the fix and in none of 6 after.
  • The device checks ran on an earlier revision. It deferred the text input until the release's gestures were raised and the root cleaned up the focus, but not past the release of the captures and the exit events. Widening the deferral to the end of the release, and deferring the re-show, were validated with the runtime tests only.

Not verified

• Touch on native WinUI: the order there was checked with a mouse, as described in the issue.
• The iOS Skia head.
• The full runtime suite.
• InputPane.skia.cs brings a captured element into view without checking it still has the focus. It's the same pattern, but it's not needed here and isn't changed.

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

🤖 Generated with Claude Code