Xamarin.forms: [UWP] TapGestureRecognizer No Longer Blocks List View Item Tapped Event

Created on 15 Dec 2017  路  14Comments  路  Source: xamarin/Xamarin.Forms

Description

TapGestureRecognizers inside the view cell of a list view no longer block the item tapped/item selected event of a list view.

Steps to Reproduce

  1. Create a list view with item tapped and or item selected events.
  2. Have a control with a tap gesture recognizer inside the view cell.
  3. Tap gesture recognizer doesn't block item tapped / item selected events.

Expected Behavior

The TapGestureRecognizer should block the item tapped / item selected event from firing. This use to be the behavior.

Actual Behavior

Both the TapGestureRecognizer and the item tapped / item selected events fire.

Basic Information

  • Version with issue: 2.5.0.121934
  • Last known good version: 2.3.4.270
  • IDE: VS 2017 15.5.1
  • Platform Target Frameworks:

    • UWP: 15063

  • Nuget Packages: Xamarin Forms
  • Affected Devices: UWP

Reproduction Link

Here is a reproduction solution
https://drive.google.com/file/d/1iud-OgALmeTw1Jf1q6xKMGG00v2xsNhF/view?usp=sharing

https://bugzilla.xamarin.com/show_bug.cgi?id=32842

gestures 馃枛 listview 6 help wanted UWP bug up-for-grabs

Most helpful comment

@samhouts Yes this is still an issue in the most recent Xamarin version. I am attaching a repo here that shows a reproduction of the bug.

https://github.com/JCookVF/UWPButtonOnListViewBugExample.git

All 14 comments

PR which may introduced the change:

https://github.com/xamarin/Xamarin.Forms/pull/842

Any chance to get this fixed in the next release?

This is blocking us from upgrading from 2.3 to 2.5 and using .NET Standard.

https://github.com/xamarin/Xamarin.Forms/pull/1157 It looks like there is a legacy mode that will allow the old behavior.

MyList.On().SetSelectionMode(ListViewSelectionMode.Inaccessible);

This bug can more than likely be closed.

Have you tested it with the reproduction sample?

It still logs:
Item Selected Fired.
Tap Gesture Command Fired.

It's workable in my case because I'm just using ItemTapped to execute a command.

private void ItemsControl_ItemTapped(object sender, ItemTappedEventArgs e)
{
    if (e.Item == null) return;
    if (ItemTappedCommand != null)
    {
        if (ItemTappedCommand.CanExecute(e.Item))
        {
            ItemTappedCommand.Execute(e.Item);
        }
    }
    if (HideDefaultSelection)
    {
        ((ListView)sender).SelectedItem = null;
    }
}

The problem is, in iOS and Android we respond to on list item taps as well as individual buttons on the list items. So without re-writting our iOS and Android apps, we need individual tap gestures firing before the item selected. (Or not at all would be best)

Last tested with 4.0.0.94569-pre3.

Events fire in this order:

Item Selected Fired.
Item Tapped Fired.
Tap Gesture Command Fired.

Any update on this? I've upgraded xamarin to the most recent releases and this is still a big issue for us. Would love to see a fix or at least a work around if anyone knows a good one.

Indeed, a fix or workaround would be nice!

At the moment we are working around this by adding a platform specific transparent button on top of the Image that has the same command as the tap gesture recognizer. This way the button gets pressed instead of the image and the button does not trigger a list view item selected event. If you're keeping the command on the gesture recognizer though it is important that the button gets placed on top so that it doesn't trigger the command twice (once for the button, once for the gesture recognizer). Aside from the extra work and code the only downside of this I have seen would be the animation of the button hover/press will now be visible (if you care about that). If that is a problem I think it can be removed via a custom renderer or effect though. I'll add a quick snip of my xaml where I've done this if you want a visual..

image

I can't remember the specifics for each platform but I'm pretty sure that placing a control programmatically after another control, like the Platform Specific tag in this case, will draw the control last on the screen? i.e. button on top of the image.

At the moment we are working around this by adding a platform specific transparent button on top of the Image that has the same command as the tap gesture recognizer. This way the button gets pressed instead of the image and the button does not trigger a list view item selected event. If you're keeping the command on the gesture recognizer though it is important that the button gets placed on top so that it doesn't trigger the command twice (once for the button, once for the gesture recognizer). Aside from the extra work and code the only downside of this I have seen would be the animation of the button hover/press will now be visible (if you care about that). If that is a problem I think it can be removed via a custom renderer or effect though. I'll add a quick snip of my xaml where I've done this if you want a visual..

image

I can't remember the specifics for each platform but I'm pretty sure that placing a control programmatically after another control, like the Platform Specific tag in this case, will draw the control last on the screen? i.e. button on top of the image.

Thanks for your example and writing this here! I'm going to try it!

This issue doesn't seem to have had any activity in a long time. We're working on prioritizing issues and resolving them as quickly as we can. To help us get through the list, we would appreciate an update from you to let us know if this is still affecting you on the latest version of Xamarin.Forms, since it's possible that we may have resolved this as part of another related or duplicate issue. If we don't see any new activity on this issue in the next 30 days, we'll evaluate whether this issue should be closed. Thank you!

@samhouts Yes this is still an issue in the most recent Xamarin version. I am attaching a repo here that shows a reproduction of the bug.

https://github.com/JCookVF/UWPButtonOnListViewBugExample.git

Was this page helpful?
0 / 5 - 0 ratings