Hitbox feature default should be the feature at point instead of default arbitrary value 44

Describe the bug The hitbox feature added to the VectorSource (and other sources) is always on, even when not set. The default value of 44 is arbitray compared to the feature size. If the hitbox is not set, it should default to triggering onPress on point instead of inside a Rect.

To Reproduce

1. Implement onPress on the source
2. Leave hitbox at default
3. Press right next to any feature

Expected behavior onPress shouldn’t be triggered

NSArray<id<MGLFeature>> *features = [mapView visibleFeaturesAtPoint:screenPoint inStyleLayersWithIdentifiers:[NSSet setWithArray:[touchableSource getLayerIDs]]];

Actual behavior onPress is triggered outside of the feature bounds because of default Rect.

NSArray<id<MGLFeature>> *features = [mapView visibleFeaturesInRect:hitboxRect
                                                     inStyleLayersWithIdentifiers:[NSSet setWithArray:[touchableSource getLayerIDs]]
                                                     predicate:nil];

Versions (please complete the following information):

• Platfrom: iOS
• Device: any
• OS: any
• React Native Version: any

Additional context Introduced by https://github.com/react-native-mapbox-gl/maps/commit/244830f2b8762d63e3632430f9813b6e5aa033d0

iOS: https://github.com/react-native-mapbox-gl/maps/blob/04f789a665287578c929cbcbc8c6e651c710f379/ios/RCTMGL/RCTMGLMapViewManager.m#L325

Android: https://github.com/react-native-mapbox-gl/maps/blob/04f789a665287578c929cbcbc8c6e651c710f379/android/rctmgl/src/main/java/com/mapbox/rctmgl/components/mapview/RCTMGLMapView.java#L543

[bartolkaruza]

The hitbox is not a minimal size for the feature (which would relate to the interface guidelines, of making any touchable element at least 44px in size), but it relates to including any feature within 44px of the touch event. The problem with this is that features that are close to each other, but on different layers, make the underlying layer untouchable (because only the found feature at position 0 in the feature array is returned from native).

Below screenshot has 2 features outlined, top layer pin outlined in blue, and cluster layer below, outlined in green. The red dot is the touch event and the red outline the reach of that touch event as to inclusion of features.

In this case the pin receives the touch event and the cluster is almost impossible to reach by touch.

These are large features, that don’t require enlarged buffers around them to make them easily touchable, but I imagine the exact same problem will occur when smaller features overlap.

Are you sure this is the default people are looking for? It took us a while to even figure out why that hitbox was causing the bug that the clusters weren’t receiving touch events in many cases. I get that it makes sense in a map that has very few interactive features, but any map that has many interactive features will face the same problem we faced.

A viable workaround is setting hitbox to 1, which is the value we arrived at after debugging the native library code and after understanding the hitbox feature implementation (which we can maybe prevent for the next person facing this by explaining the hitbox default implication in the docs).

[andersonvom]

At the very least, it sounds like the default hitbox should be different, depending on the specific component handling the onPress event, so that the scenarios mentioned by @kristfal (i.e. tiny/thin elements can still be interacted with) can be accommodated, while allowing for larger elements not to be mistaken with nearby larger elements, which is a pretty poor experience.

Alternatively, if the somewhat large hitbox is required everywhere, if the returned features were sorted by proximity to the actual hit location, it’d be a little easier to mitigate the issue on the client side, though I still think a more reasonable default hitbox, as @bartolkaruza mentioned, is the way to go.