fix(input): Don't click an element when a long press opened its context flyout - #25126

GitHub Issue: closes #22229

PR Type:

🐞 Bugfix

What changed? 🚀

On Skia, a touch hold on an element with a ContextFlyout inside a pannable or draggable ancestor (a ScrollViewer, a ListView, ...) defers the context request by 500 ms after the Holding gesture, so that a pan or drag can still start (ContextMenuProcessor, ported from WinUI). That timer was never stopped.

• The bug: a finger lifted after the hold started (800 ms) but before the delayed menu clicked the element, because ButtonBase was still pressed and captured. The flyout then popped up a few hundred milliseconds later. That is the "click and context menu" of the issue.
• Already correct: when the hold lasts until the flyout opens, the flyout takes focus and ButtonBase.OnLostFocus drops the pressed state, so the release does not click.

Changes:

• The timer is now stopped. ContextMenuProcessor.StopContextMenuTimer() stops the delayed context menu when:

  • a second pointer is pressed;
  • the pointer is released;
  • the pointer is cancelled, which includes a DirectManipulation taking over (InputManager);
  • a drag starts from the hold (UIElement.StartDragAsyncCore).

  WinUI stops it in PointerInputProcessor.cpp on pointer down, pointer up, cancel, capture change and suspension. Uno has no window-level capture change, so the drag start stands in for it. The behavior that results:

  • A hold released before the delayed menu is a plain click with no flyout.
  • A hold that reaches the menu opens it without clicking.
  • A drag started from the hold no longer gets the menu in the middle of the drag.
  • A second finger pressed before the delayed menu drops it.

• The timer is shared. As in WinUI, there is one context menu timer per content root, so any press or release stops a pending one. A mouse button change while another button is held also stops it, which WinUI doesn't do; that only matters while another pointer's touch hold is pending.

• A new hold also stops it, as the two holds would share the touch point. This is needed when two fingers are pressed less than 500 ms apart: the second press comes before the first hold creates the timer, so only the second hold can drop it.

• TextBox and PasswordBox act when the hold starts. Their touch conventions (Android word select, iOS caret drag, empty-field flyout) relied on that stray post-release timer, because the text viewport is a pannable ScrollViewer. Like WinUI's CTextBoxBase::OnHolding (TextBoxBase.cpp), they now act on OnHolding with HoldingState.Started:

  • The hold first takes focus, which touch otherwise defers to the release. It takes pointer focus even when the control is already focused from the keyboard. Otherwise the release would take it, and that focus state change resets the caret mode, which hides Android's selection handles.
  • A hold that can't take focus does nothing, as in WinUI's TextSelectionManager::OnHolding (selectable text): no word select or caret drag. Its delayed ContextRequested doesn't act on the unfocused control or open the flyout either, because these conventions replace the flyout.
  • They handle the delayed ContextRequested of the same hold without opening the flyout.
  • They don't treat the release of a handled hold as a tap.
  • A hold released within the tap range is also a touch right-tap, and they no longer move the caret on it. Before, that right-tap put the caret back at the press point and undid an iOS caret drag. WinUI's CTextBoxBase::OnRightTapped doesn't move the caret on a touch right-tap either. Mouse, pen and the Desktop convention are unchanged.
  • For users, Android's word select starts when the hold is recognized (0.8 s) instead of 1.3 s. That is closer to native Android, which starts it at its own, shorter long press (about 0.4 to 0.5 s).
  • Under the iOS convention, the press-and-hold acts after UIKit's 0.5 s, on a timer of its own (feat(textbox): Follow native iOS touch text editing #25619). That timer now takes focus first in the same way, and does nothing when it can't. The Holding and the delayed ContextRequested of a hold it handled don't act again.

Tests

Input injection, Skia:

• Given_Button.When_ContextFlyout_In_ScrollViewer_Touch_Released_Before_Delayed_Flyout asserts one click and no flyout. It fails on master, where the flyout opens after the release, and passes with this PR.
• Given_ContextRequested_Injection.When_Touch_Hold_Starts_Drag_Delayed_ContextFlyout_Does_Not_Open holds a draggable element and starts a drag. It fails without the stop on drag start.
• Given_ContextRequested_Injection.When_Touch_Hold_Then_Second_Finger_Pressed_Delayed_ContextFlyout_Does_Not_Open holds an element in a ScrollViewer, then presses a second finger elsewhere during the delay and keeps it down. It fails without the stop on press.
• Given_ContextRequested_Injection.When_Two_Fingers_Held_Second_Hold_Drops_First_Delayed_ContextFlyout presses a second finger 250 ms after the first and holds both. It fails without the stop on a new hold.
  • The holds come from each finger's 800 ms hold timer, so the overlap depends on the machine's timing. The test checks it: when the second hold is raised, the first one's delayed request must still be pending, and each hold must have its own finger as source (a hold takes its source from the last pointer event).
  • An attempt that misses this is retried, up to three times, and the test then fails rather than skipping its assertion.
• Given_PasswordBox.When_Touch_Hold_Focuses_At_Hold_Start_Android holds an unfocused password box. The hold must take focus before the release, and the delayed request must not open a flyout.
• Given_TextBox.When_Touch_LongPress_Unfocused_Selects_Word_Android holds an unfocused text box and checks that the hold focuses it and selects the word.
• Given_TextBox.When_Touch_LongPress_Keyboard_Focused_Keeps_Handles_Android and Given_PasswordBox.When_Touch_Hold_Keyboard_Focused_Keeps_Handles_Android start focused from the keyboard and check that the selection handles survive the release. They run with SelectionFlyout = null, so no flyout opens after the hold. Both fail if the hold only takes focus when unfocused.
• Given_TextBox.When_Touch_LongPress_Not_Focusable_Does_Nothing_Android holds a text box with IsTabStop set to false, which can't take focus. Neither the hold nor its delayed request may select the word or open a flyout. It fails if the hold is only marked as handled once the focus succeeds.
• Given_TextBox.When_Touch_LongPress_Not_Focusable_Does_Nothing_iOS does the same under the iOS convention: the hold timer must not start a caret drag (the caret stays at 0, nothing captures the finger). It fails without the focus check in the timer.
• Given_TextBox.When_Touch_Held_Past_Delayed_ContextRequested_No_Flyout_iOS drags the caret and holds past the delayed request. The request must not open the flyout or turn the caret into a selection. The injected timestamps are carried past the hold delay, so the release is a right-tap, which must not move the caret back to the press point. That last check fails without the right-tap fix.
• Given_Button.When_ContextFlyout_Touch_LongPress_Opens_Flyout_Without_Click, When_ContextFlyout_In_ScrollViewer_Touch_Held_Until_Delayed_Flyout_Opens and When_ContextFlyout_RightClick_Opens_Flyout_Without_Click are regression coverage for the paths that already behaved.
  • They wait for the hold or the flyout instead of fixed delays.
  • Like the other finger tests in Given_Button, they run on Uno only.

Driving ContextMenuProcessor directly:

• Given_ContextRequested.When_Touch_Hold_On_Non_Pannable_Then_Pending_Delayed_Request_Is_Dropped checks that a hold on a non-pannable element drops a pending delayed request. Otherwise that request would fire later at the new hold's position. With real input this happens when two fingers are pressed less than 500 ms apart: the second press comes before the first hold creates the timer, so only the second hold can drop it.

Skia desktop validation: Given_Button, Given_ContextRequested*, Given_TextBox, Given_PasswordBox, Given_MenuFlyout, Given_Flyout*, Given_CommandBar, Given_UIElement and Given_FlipView were run.

• After the review fixes: Given_Button, Given_ContextRequested*, Given_TextBox and Given_PasswordBox were run again. The only failures were Given_TextBox.When_Caret_Line_Straddles_Viewport_Edge_Grippers_Are_Hidden and When_Scrolling_Updates_With_Movement.
  • Both failed the same way in the runs before the review fixes.
  • Neither involves a touch hold: one checks the gripper pixels after a tap, the other only sends keys.
• Pre-existing failures: layout and placement failures that reproduce on master on the same machine (125 % display scaling).
• Intermittent failure: Given_FlipView.When_TouchFlick_Then_FlipOneItem failed in one of two full local runs and in the first CI run of this PR.
  • It passes on its own and in smaller groups, and passed in a full master run.
  • I found no code path from these changes into a plain flick: the delayed menu only exists after a Holding gesture, and stopping it is a no-op otherwise.
  • The test is already excluded on several targets for flakiness.
• After merging master (e027860; the iOS touch editing of feat(textbox): Follow native iOS touch text editing #25619 and the deferred release of fix(input): Raise Tapped and RightTapped after PointerReleased bubbles #25818 touched the same code): Given_Button, Given_ContextRequested*, Given_TextBox and Given_PasswordBox, 441 of 444 passed and Given_TextBox.When_CanPasteClipboardContent_Changes_Without_Peer_Then_No_Peer_Is_Created was inconclusive (it reads the clipboard). When_Touch_LongPress_Not_Focusable_Does_Nothing_iOS failed there, as the iOS hold timer didn't check focus yet, and so did Given_TextBox.When_Touch_LongPress_Drag_Release_Does_Not_Open_Flyout_iOS, which fails the same way on master on this machine (125 % display scaling).
• At 6317c1e (the hold timer takes focus): the 116 hold, context flyout and iOS-convention tests, When_Touch_LongPress_Not_Focusable_Does_Nothing_iOS included, pass except When_Touch_LongPress_Drag_Release_Does_Not_Open_Flyout_iOS.
• At 5be4b1b (the final head): Given_Button, Given_ContextRequested*, Given_TextBox and Given_PasswordBox, 442 of 444 pass. The clipboard test is inconclusive and When_Touch_LongPress_Drag_Release_Does_Not_Open_Flyout_iOS fails, both as on master.

Behaviour to be aware of

• A hold released before the delayed menu still clicks. This matches WinUI: a touch hold released that early is a right-tap.
  • ButtonBase::OnPointerReleased (ButtonBase_Partial.cpp) doesn't click when GestureFollowing is RightTapped. OnRightTappedUnhandled then clicks if the right-tap wasn't handled.
  • For touch, the context request only comes from the hold. InputServices.cpp raises ContextRequested on a right-tap for mouse and pen only.
• A selectable TextBlock released between the hold and the delayed menu now neither taps nor opens the menu. That matches WinUI, where TextSelectionManager::OnHolding only takes focus for touch and the pointer up stops the delayed menu.
• A handled RightTapped still cannot suppress a hold-release click (touch, or a pen long-press) as it does in WinUI. PointerRoutedEventArgs.GestureFollowing is not implemented, and ButtonBase clicks from PointerReleased. That is a separate parity gap and is unchanged here.
• Moving the finger without a DirectManipulation or a drag starting doesn't drop the delayed menu, as before. An example is a horizontal slide in a vertical-only ScrollViewer.

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