Open david-maw opened 1 week ago
We've found some similar issues:
If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.
Note: You can give me feedback by 👍 or 👎 this comment.
This issue has been verified using Visual Studio 17.12.0 Preview 5(9.0.0-rc.2.24503.2 & 8.0.92). Can repro this issue at android platform
I think this is correct behaviour. If you have a collection view and tap it, I would assume you want the taps to be handled by the collection view. Passing the tap through would break the collection view as you would no longer be able to select or scroll.
I am thinking this may also happen with a list of labels in a scroll view. The scrolling controls have to handle the touches in order to be able to detect if you want to scroll or not.
@ninachen03 did you test Windows? I see the title says Android, but the description mentions both Android and Windows.
I did test Windows, but the results were strangely inconsistent, sometimes taps were passed through, sometimes not and because I have not figured out why and when I focused on Android (which is what I really cared about anyway). The windows UI is different in that scrolling is initiated by a scroll wheel on a mouse rather than a gesture on the control itself (though I don't know how it behaves on a touch screen).
I could more easily live with an "as designed" answer if it were not for #10213 which in the more general case means putting any gesture recognizer on the CollectionView disables gesture-based scrolling. This is about handling gestures the CollectionView does not use. In practice it is mostly gestures in the open space after a partially filled CollectionView, gestures on the items might well be intercepted by the items themselves.
Passing through a Tap might inhibit selection, but if the tapped item intercepts the tap anyway it'll never reach the CollectionView and might well be coded to select (and, in my case, deselect) that item when tapped. Still, I agree that "should we pass through the tap" is tricky, maybe the answer is the moral equivalent of InputTransparent
but only for the tap gesture.
All that said, you can. for example, have a tap gesture recognizer on an item in a CollectionView without disabling the native scrolling on the CollectionView. You can even have a SwipeGetureRecognizer but swipe Up and Down will be passed to the CollectionView and used for scrolling, only left and right do anything.
@mattleibow correct behavior?
I am having this CollectionView gesture issue, for quite some time. (Late 22) And also this: https://github.com/dotnet/maui/issues/18569
I will not get into arguments how this should propagate and who actually is expected to "consume" the gesture. (Not that I don't want to) And I would agree basically with any decision. As long as it is consistent.
What really disturbs me is that on Android it does "X", on IOS "Y", on Windows "Z". How can any of this be "correct behavior".
Explain to me again, why I should be able scroll and pinch on IOS, and not on Android.
Description
The setup is a CollectionView inside a grid. The grid has gesture recognizers defined, the CollectionView does not.
Tapping on the page triggers the tap gesture recognizer unless you tap within the CollectionView in which case the tap is ignored on Android and Windows.
Steps to Reproduce
Clone the repository, build and run the app. You should see:
Tap on the page and the tap will be reported unless you tap within the CollectionView.
Link to public reproduction project repository
https://github.com/david-maw/SimpleCollectionView-missing-gestures.git
Version with bug
9.0.0-rc.2.24503.2
Is this a regression from previous behavior?
No, this is something new
Last version that worked well
Unknown/Other
Affected platforms
Windows, Android, I was not able test on other platforms
Affected platform versions
Windows 11, Android 14
Did you find any workaround?
Sort of....
You can attach a GestureRecognizer to the CollectionView but doing so will inhibit native CollectionView scrolling on Android so you then must implement your own scrolling logic (there is an example in the test case, just commented out). If it were not for the fact that the GestureRecognizer inhibits scrolling on Android (see #10213), I'd have just assumed this was a feature.
Relevant log output