[Regression] ListBoxItems and children no longer reliably generate Tapped events from Touch input.

[IanRawley]

Describe the bug

ListBoxItems or their children (with the exception of Buttons at least) no longer generate Tapped events or trigger Tapped event handlers when the input comes from a touch device. Mouse clicks still generate Tapped events as expected. Both generate DoubleTapped events.

To Reproduce

Steps to reproduce the behavior:

1. Clone https://github.com/IanRawley/ListBoxItemTappedInteractions.git and build as is.
2. Run on a touch enabled device, and see that tapping either the Buttons or Border/Textblocks increment the appropriate counter.
3. Update solution to Avalonia 11.0.5 and rebuild.
4. Tapping the Border/Textblocks no longer increments the appropriate counter. Buttons are unaffected. Using a mouse to click the Border/Textblocks will increment the counter though.

Expected behavior

Both mouse input and touch input generate Tapped events.

Environment

• OS: Windows 11 / Android.
• Avalonia-Version: 11.0.4 - OK / 11.0.5 - Broken.

Additional context

Looking through the list of commits from Avalonia 11.0.4 to 11.0.5 the only one that seems potentially relevant is #12666,
although I don't know nearly enough about the whole GestureRecognizer system to comment with any certainty.

Using a Surface Go 4 to check has been a boon, as the use of DevTools has allowed me to confirm that nowhere within the bounds of a ListBoxItem is generating Tapped events from touch input, with the exception of the bounds of the Button.

[IanRawley]

Looking at it some more after the weekend, the problem seems to be that while PointerPressed events have their source set to the appropriate Textblock/Border/etc control, corresponding PointerReleased events have their source set to the ListBox. As they don't match, no Tapped events are generated. DoubleTapped is generated on PointerPressed, so there's no issue. This only applies to Touch pointers though, Mouse pointers generate PointerReleased events with the appropriate source set. I'm going to try and figure out why Touch pointers are creating PointerReleased events with unexpected sources.

[IanRawley]

The PointerReleasedEventArgs are initially getting created with the correct source, but ListBoxItem is doing the following in its own OnPointerReleased():

// As we only update selection from touch/pen on pointer release, we need to raise
// the pointer event on the owner to trigger a commit.
if (e.Pointer.Type != PointerType.Mouse)
       owner.RaiseEvent(e);

Calling owner.RaiseEvent(e) causes the source of the event to be overwritten with owner, in this case the ListBox, which results in Tapped event generation breaking because the PointerPressed and PointerReleased events now have different sources.

That puts the cause of the regression as Commit #12883.

[IanRawley]

So I'm looking into this more and trying to prep a PR, because this is a pretty big problem I feel, and I'm a bit confused about some of the Unit Test helpers. Specifically the TouchTestHelper. The TouchTestHelper raises the various pointer events with no mouse button, which makes sense given we're taking about touch, but in the wild the real events are LeftMouseButton related. TouchDevice seems to, by default, make Pointer event args with LeftMouseButton pressed. Tapped events are also only generated if there is a Left or Right mouse button pressed.

Does this mean I shouldn't be using the TouchTestHelper, because it doesn't reflect real life use cases, or that TouchTestHelper should be changed to assume a Left mouse button touch unless otherwise specified?

[timunie]

@emmauss do you have any hints?

[IanRawley]

My proposed fix is essentially rolling back the change made to ListBoxItem as part of the AutoCompleteBox focus fixes. Looking into every bit I can think of I'm still not sure why the event needs to be raised again, rather than simply bubbling up to the ListBox. I'd appreciate any insight on that suggestion as well.