[Bug]: [Android] ShapeSource hitbox is applied in physical pixels, not points — target shrinks with screen density

Mapbox Implementation

Mapbox

Mapbox Version

11.20.1

React Native Version

0.86.2

Platform

Android

@rnmapbox/maps version

10.3.1 (also present on main)

Standalone component to reproduce

import * as React from 'react';
import { MapView, ShapeSource, CircleLayer, Camera } from '@rnmapbox/maps';

// Tap slightly off-centre from the dot — say 18dp away. On a 1x/2x device it
// registers; on a 3x device it usually does not.
const point = {
  type: 'Feature' as const,
  geometry: { type: 'Point' as const, coordinates: [2.35, 48.86] },
  properties: {},
};

const HitboxTest = () => (
  <MapView style={{ flex: 1 }}>
    <Camera centerCoordinate={[2.35, 48.86]} zoomLevel={14} animationDuration={0} />
    <ShapeSource id="pt" shape={point} onPress={(e) => console.log('hit', e.features.length)}>
      <CircleLayer id="pt-circle" style={{ circleRadius: 6, circleColor: '#c00' }} />
    </ShapeSource>
  </MapView>
);

Observed behavior and steps to reproduce

The default ShapeSource touch hitbox is documented as 44×44 points, but on Android it behaves as 44×44 physical pixels. The effective touch target therefore shrinks as screen density rises:

density	effective target
1x (mdpi)	44dp (correct)
2x (xhdpi)	~22dp
3x (xxhdpi, e.g. Pixel 10 Pro)	~14.7dp

Steps:

1. Render the component above on a 3x-density Android device.
2. Tap a few dp away from the dot's centre (still visually on/next to it).
3. onPress does not fire, while the same offset registers on iOS or on a lower-density device.

The dot is harder to hit on Android than on iOS, and gets progressively harder on higher-density hardware. Passing an explicit hitbox works around it, but the value must then be pre-scaled by PixelRatio on Android only — which is itself surprising, since the prop is documented in points.

Expected behavior

The default hitbox should be 44dp on every density, matching the documented value and the iOS behaviour. An explicit hitbox={{ width, height }} should be interpreted in density-independent points on both platforms, so the same value gives the same physical target size everywhere.

Notes / preliminary analysis

The units are mismatched at the point where the hitbox meets the screen coordinate.

RNMBXMapView.onMapClick obtains the tap position in physical pixels:

val screenPointPx = mMap?.pixelForCoordinate(point)

That value is passed straight into handleTapInSources, which subtracts the raw hitbox halves from it without any density conversion:

val halfWidth = (hitbox["width"]!!.toFloat() / 2.0f).toDouble()
val halfHeight = (hitbox["height"]!!.toFloat() / 2.0f).toDouble()
val screenBox = ScreenBox(
        ScreenCoordinate(screenPoint.x - halfWidth, screenPoint.y - halfHeight),
        ScreenCoordinate(screenPoint.x + halfWidth, screenPoint.y + halfHeight)
)

hitbox["width"] is either the JS-supplied number or DEFAULT_HITBOX_WIDTH = 44.0 from RNMBXSource.kt — in both cases a point value, now being subtracted from a pixel coordinate.

The file already knows about this distinction, and converts correctly a few lines later for the emitted event:

/** Android Mapbox SDK returns screen coordinates in physical pixels, while JS expects density-independent pixels. */
val screenPointDp = toDp(screenPointPx)

So the outgoing point is converted but the incoming hitbox is not. The same file already has the exact helper needed — private fun toPx(boxDp: ScreenBox): ScreenBox — which is currently unused on this path.

iOS is unaffected: RNMBXMapView.swift builds its hitboxRect from a CGPoint that is already in points.

Building the box in dp and passing it through that helper would fix it (untested, and I have not opened a PR — the maintainers will know whether the conversion belongs here or in touchHitbox):

val screenBox = toPx(ScreenBox(
        ScreenCoordinate(screenPointDp.x - halfWidth, screenPointDp.y - halfHeight),
        ScreenCoordinate(screenPointDp.x + halfWidth, screenPointDp.y + halfHeight)
))

Note this would change the effective target size for anyone currently compensating with a pre-scaled hitbox, so it is arguably a breaking change on Android.

Additional links and references

• android/src/main/java/com/rnmapbox/rnmbx/components/mapview/RNMBXMapView.kt — handleTapInSources (hitbox subtraction) and onMapClick (pixelForCoordinate / toDp)
• android/src/main/java/com/rnmapbox/rnmbx/components/styles/sources/RNMBXSource.kt — DEFAULT_HITBOX_WIDTH / DEFAULT_HITBOX_HEIGHT and touchHitbox
• Found while working around #3800; unrelated to that issue's latency cause, but it compounds the symptom — taps feel both slow and unreliable on high-density Android.

Start in android/src/main/java/com/rnmapbox/rnmbx/components/mapview/RNMBXMapView.kt, reading handleTapInSources and onMapClick alongside the existing toDp and toPx helpers. Then inspect RNMBXSource.kt for the default and explicit hitbox values. Done means default and supplied hitboxes produce the documented density-independent target on Android; verify the supplied reproduction across screen densities and run any relevant existing tests.