[$250] BUG: Chart bars missing tooltips and clickable links to expense search

[melvin-bot]

Bug Description

Every bar on the chart should have a tooltip, and clicking on any bar in the chart should link to a search showing the expenses that comprise that bar.

Current behavior:

• No tooltip is shown when hovering over chart bars
• Clicking a bar does not navigate anywhere

Expected behavior:

• Each bar should display a tooltip with relevant data
• Clicking a bar should navigate to a search filtered to the expenses that make up that bar

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060895478975582679
• Upwork Job ID: 2060895478975582679
• Last Price Increase: 2026-05-31

[MelvinBot]

Proposal

What is the root cause of that problem?

Tooltips and tap handlers on SearchBarChart (and SearchLineChart) are wired up in our code, but the gestures never fire because Victory-Native's CartesianChart always renders an absolutely-positioned GestureDetector overlay on top of the plot area, and our outer <GestureDetector> wraps that overlay.

BarChartContent builds customGestures from useChartInteractions and wraps the chart with <GestureDetector gesture={customGestures}>, but does not forward customGestures to <CartesianChart> itself.

Inside victory-native, CartesianChart does (node_modules/victory-native/src/cartesian/CartesianChart.tsx lines 724-763):

let composed = customGestures ?? Gesture.Race();
// ...
gestureOverlay = <GestureHandler gesture={composed} dimensions={plotArea}/>

GestureHandler then renders <GestureDetector gesture={composed}><Animated.View style={{position: 'absolute', ...}}/></GestureDetector> over the plot area. With react-native-gesture-handler, when nested GestureDetectors exist, the inner one wins for the area it covers. Because we don't pass customGestures to Victory, the inner detector is an empty Gesture.Race() that absorbs every tap/hover on the bars and never propagates them to our outer gesture — so matchedIndex and isTooltipActive stay at their defaults, the tooltip layer stays at opacity: 0, and handleBarPress is never called.

The downstream pieces (SearchBarChart.handleBarPress, SearchChartView.handleItemPress, and chartGroupByConfig.ts) are all correct — they just never get a chance to run.

What changes do you think we should make in order to solve the problem?

Pass customGestures to CartesianChart so Victory's overlay uses our gestures instead of the empty Gesture.Race(). The wrapper <GestureDetector> can then be removed (or kept only if we still need to detect interactions outside the plot area, e.g. on the x-axis labels):

• In src/components/Charts/BarChart/BarChartContent.tsx, forward customGestures to <CartesianChart customGestures={customGestures} ...>.
• Apply the same fix in src/components/Charts/LineChart/LineChartContent.tsx — it has the identical wiring bug.
• Verify that label hit-testing (isCursorOverLabel, findLabelCursorX) still works once the gesture lives inside the plot-area overlay; if not, keep the outer <GestureDetector> for the label area only.

Investigation details

Symptoms explained:

• No tooltip on hover → hoverGesture.onBegin/onUpdate in useChartInteractions never fires → matchedIndex.value = -1 and isTooltipActive.value = false → ChartTooltipLayer renders with opacity: 0.
• No navigation on tap → tapGesture.onEnd never fires → handleBarPress is never called → onBarPress → onItemPress → Navigation.navigate chain never starts.

Evidence chain:

1. Touch hits Victory's inner GestureHandler overlay first (RNGH child-wins rule).
2. That overlay has an empty Gesture.Race() → never activates, never propagates.
3. Outer <GestureDetector gesture={customGestures}> on BarChartContent.tsx:258 never receives the event.

Alternative explanations considered:

• getFilterQuery returning empty → ruled out, all entries in chartGroupByConfig.ts return non-empty strings.
• onBarPress not threaded through → ruled out, prop chain SearchChartView → SearchBarChart → BarChartContent is intact.
• ChartTooltipLayer rendering issue → ruled out, it just consumes matchedIndex / isTooltipActive which never change.

What alternative solutions did you explore? (Optional)

• Setting pointerEvents="none" on Victory's inner overlay when no customGestures are passed — would require patching victory-native and is unnecessary once we just pass our gestures through.
• Wrapping the chart in <View pointerEvents="box-only"> — doesn't help because the inner GestureDetector still claims the touch via RNGH before React Native pointer events propagate.

Related issues

• [$250] Chart should maintain aspect ratio when window/screen size changes #92147 (chart aspect ratio) — same chart component, unrelated bug.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92149) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The search chart drill-down path is already wired: SearchBarChart passes a bar press to SearchChartView, and SearchChartView builds a table search route from the selected chart group.

The break is in the shared bar chart hit-test. BarChartContent stores the chart zero baseline in yZero and sets it from yScale(0), but handleChartBoundsChange resets the same shared value to 0 afterward. checkIsOverBar then compares the cursor against the area between the bar value point and yZero. A canvas Y value of 0 is the top of the chart, not the zero baseline, so the hit rectangle is above positive bars instead of over the visible bar body.

useChartInteractions only shows the tooltip and calls the press handler when that hit-test passes, so the wrong baseline suppresses both bar tooltips and the existing navigation.

What changes do you think we should make in order to solve the problem?

Fix the bar chart interaction geometry instead of adding search-specific overlays.

• In src/components/Charts/BarChart/BarChartContent.tsx, stop resetting yZero to 0 in handleChartBoundsChange.
• Keep setting yZero from yScale(0) in handleScaleChange, because that is the real canvas coordinate for the zero baseline.
• Make the bar hit-test fall back to the chart bottom only when a valid baseline is not available yet, then compute the hit rectangle from targetY to the resolved baseline so positive and negative bars continue to work.
• Leave the existing SearchBarChart and SearchChartView drill-down flow unchanged. No backend/API behavior needs to change.
• Add focused coverage for the bar interaction path so hovering over a visible bar activates the tooltip state and tapping the same area calls the press callback.

This affects generic bar chart interactions anywhere BarChartContent is used, including expense search charts and the spend-over-time widget.

What alternative solutions did you explore? (Optional)

I considered adding a separate clickable overlay in SearchBarChart or changing the search navigation code, but that would duplicate chart interaction logic and would not fix generic bar tooltips. The broken part is the shared bar hit-test baseline.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @gijoe0295 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022060895478975582679

[ReaperOAK]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Bar chart bars in the expense search chart view show no tooltips on hover and do not navigate to filtered search results when clicked, despite the drill-down plumbing in SearchBarChart and SearchChartView being correctly wired up.

What is the root cause of that problem?

The root cause is in src/components/Charts/BarChart/BarChartContent.tsx at lines 123–131, inside handleChartBoundsChange, where the shared Reanimated value yZero is reset to the literal 0 instead of yScale(0).

// src/components/Charts/BarChart/BarChartContent.tsx L123-L131
const handleChartBoundsChange = useCallback(
    ({chartBounds, yScale}: ChartBoundsWithScales) => {
        // ...other bound assignments...
        yZero.value = 0;   // ← BUG: 0 is the TOP of the Skia canvas, not the zero baseline
    },
    [yZero, /* ... */],
);

checkIsOverBar at lines 133–148 uses yZero.value as the bottom edge of each bar's hit rectangle:

// src/components/Charts/BarChart/BarChartContent.tsx L133-L148
function checkIsOverBar(cursorX, cursorY, barValueY, barCenterX, barWidth) {
    return (
        cursorY >= barValueY &&          // bar top (canvas y grows downward)
        cursorY <= yZero.value &&        // bar bottom ← always 0, i.e. the canvas TOP
        Math.abs(cursorX - barCenterX) <= barWidth / 2
    );
}

In Skia/React-Native canvas coordinates y = 0 is the top of the canvas. The true zero-data baseline sits at the bottom of the plot area, which yScale(0) correctly maps to (e.g., ~280 px for a typical chart height). Because yZero.value is 0, the condition cursorY <= 0 is never satisfied for any real cursor position, so every hit-test returns false.

This means matchedIndex never updates and isTooltipActive stays false inside useChartInteractions.ts (lines 141–171 and 233–263), which suppresses both tooltip rendering and the handleBarPress → handleItemPress navigation call in SearchBarChart / SearchChartView.

The downstream code is confirmed correct at these commit-pinned URLs cited by KJ21-ENG:

• src/components/Search/SearchBarChart.tsx L21–42
• src/components/Search/SearchChartView.tsx L53–70

The only broken link in the chain is the hit-test baseline.

What changes do you think we should make in order to solve the problem?

File: src/components/Charts/BarChart/BarChartContent.tsx

Change handleChartBoundsChange to assign yScale(0) — the canvas y-coordinate of the data-zero baseline — instead of the literal 0. Add a null-guard so an invalid yScale (possible on first layout before Victory-Native has a calibrated scale) falls back to chartBounds.bottom, which is the physical bottom of the plot area and is always correct for the non-negative values enforced by useDynamicYDomain.

 const handleChartBoundsChange = useCallback(
     ({chartBounds, yScale}: ChartBoundsWithScales) => {
-        // ...
-        yZero.value = 0;
+        // yScale(0) gives the canvas y of the data zero line.
+        // Fall back to chartBounds.bottom when yScale is not yet calibrated.
+        yZero.value = yScale ? yScale(0) : chartBounds.bottom;
     },
-    [yZero, /* existing deps */],
+    [yZero, /* existing deps — no new deps needed */],
 );

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

In the search chart views, hovering a bar does not show a tooltip and clicking/tapping a bar does not navigate to a filtered expense search. Expected: each bar shows its tooltip on hover/touch, and tapping/clicking a bar opens the expense list filtered to that bucket. The wiring downstream (SearchBarChart.handleBarPress → SearchChartView.handleItemPress → chartGroupByConfig → Navigation.navigate) is correct, but the gestures that drive matchedIndex / isTooltipActive / handlePress never fire.

What is the root cause of that problem?

Victory-Native's CartesianChart always renders its own absolutely-positioned GestureDetector overlay covering the plot area, initialized from its customGestures prop (defaulting to an empty Gesture.Race() when nothing is passed). With react-native-gesture-handler's child-wins rule, that inner overlay intercepts every touch/hover on the bars before our outer <GestureDetector gesture={customGestures}> at src/components/Charts/BarChart/BarChartContent.tsx:258 (and the equivalent wrapper in src/components/Charts/LineChart/LineChartContent.tsx) can see them.

BarChartContent builds customGestures via useChartInteractions (src/components/Charts/hooks/useChartInteractions.ts:282 — Gesture.Race(hoverGesture(), tapGesture())) and applies them only to the outer wrapper, not to <CartesianChart>. The hook's own comment at useChartInteractions.ts:177-181 acknowledges this overlay exists but assumes routing gestures through the outer wrapper is sufficient; in practice the inner empty-Race detector activates first on the plot area and never propagates, so:

• hoverGesture().onBegin/onUpdate never runs → chartInteractionState.isActive stays false → isTooltipActive (useChartInteractions.ts:171) is false → ChartTooltipLayer renders at opacity: 0.
• tapGesture().onEnd never runs → scheduleOnRN(handlePress, idx) (useChartInteractions.ts:259) is never called → onBarPress → onItemPress → Navigation.navigate never fires.

The checkIsOverBar/yZero baseline is not the cause — handleScaleChange resets yZero to yScale(0) (BarChartContent.tsx:114) after handleChartBoundsChange zeroes it, so the hit-rect is correct by the time gestures arrive; they simply never arrive. Likewise, the hook already wires both a Hover gesture (web) and a Tap gesture (mobile), so the bug is not 'no touch activation path' — both paths exist and are both being swallowed by the inner overlay.

This is a regression-contract issue introduced when the chart was migrated to Victory-Native: the migration moved gesture handling to the wrapper to also cover the x-axis label area, but did not forward the same gesture into the plot-area overlay that Victory unconditionally renders.

What changes do you think we should make in order to solve the problem?

Forward customGestures to CartesianChart itself so Victory's internal overlay uses our gestures instead of the empty Gesture.Race(), while keeping the outer detector responsible only for the x-axis label area (which Victory's overlay does not cover):

1. In src/components/Charts/hooks/useChartInteractions.ts, expose two gesture bundles instead of one: a plotGestures (the existing Gesture.Race(hoverGesture(), tapGesture())) to be passed to CartesianChart's customGestures prop, and a labelGestures containing just the label-area hover/tap path (it already calls resolveLabelTouchX when e.y >= chartBottom) for the outer wrapper. Keep findClosestPoint / checkIsOver / isCursorOverLabel exactly as today.
2. In src/components/Charts/BarChart/BarChartContent.tsx (and the parallel src/components/Charts/LineChart/LineChartContent.tsx), pass plotGestures to <CartesianChart customGestures={plotGestures} ...> and keep <GestureDetector gesture={labelGestures}> only around the wrapper. Both charts share the same hook so they are fixed together.
3. No changes to SearchBarChart, SearchChartView, chartGroupByConfig, or ChartTooltipLayer — verified via the call-site enumeration that those consumers are already correctly wired and only fail because they never receive an active matchedIndex / handleBarPress invocation.

Why this layer: the broken contract is between our gesture composition and Victory's plot-area overlay, which exists for every consumer of useChartInteractions. Fixing it inside the shared hook + the two *ChartContent files covers every chart in the app (verified against the 10 BarChartContent and 8 LineChartContent consumer sites in the call-site enumeration) without touching any leaf search component.

What alternative solutions did you explore? (Optional)

• Adding a Pan/LongPress activation gesture (posted proposal angle). Rejected: it patches a symptom on touch but does not explain the web hover failure, and would not help on mobile either because Victory's inner overlay would still swallow the new gesture exactly as it swallows the existing Tap.
• Fixing yZero so checkIsOverBar returns true (competitor 2 angle). Rejected after verification: handleScaleChange (BarChartContent.tsx:113-119) already calls yZero.set(yScale(0)) after handleChartBoundsChange resets it, so the hit-rect is correct. The hit-test is never reached because the gesture itself is intercepted upstream.
• Removing the outer <GestureDetector> entirely and relying only on the inner Victory overlay. Rejected: that would break label-area hover/tap handling that the existing resolveLabelTouchX path was added specifically to support.

[trasnake87]

Proposal

Hovering a bar shows no tooltip and clicking a bar navigates nowhere, even though the same gestures do fire when the pointer is over the x-axis label strip beneath the plot — that asymmetry is the tell.

Root cause

The interaction pipeline is fully wired: SearchChartView → SearchBarChart (onBarPress) → BarChartContent.handleBarPress (src/components/Charts/BarChart/BarChartContent.tsx:64-72) → useChartInteractions (handlePress/tapGesture). The tooltip layer and chartGroupByConfig.ts navigation are also correct. The gestures simply never resolve a bar, for two combined reasons:

1 - Our gestures are attached only to the outer container. BarChartContent wraps everything in a single <GestureDetector> and deliberately does not forward the gesture into the chart, per the design note at src/components/Charts/hooks/useChartInteractions.ts:173-180 ("must NOT be passed to CartesianChart's customGestures prop, because Victory's internal GestureHandler view only covers the plot area and would drop events from the label area"):

// src/components/Charts/BarChart/BarChartContent.tsx:258-289 (abridged)
<GestureDetector gesture={customGestures}>
    <Animated.View style={[styles.chartContent, dynamicChartStyle, cursorStyle]} onLayout={handleLayout}>
        {chartWidth > 0 && (
            <CartesianChart xKey="x" /* …no customGestures prop… */ data={chartData}>
                {({points, chartBounds}) => points.y.map((point) => renderBar(point, chartBounds, points.y.length))}
            </CartesianChart>
        )}
        <ChartTooltipLayer /* … */ />
    </Animated.View>
</GestureDetector>

2 - Victory always renders its own gesture overlay on top of the plot area. CartesianChart unconditionally mounts an absolutely-positioned, transparent gesture surface over the bars, regardless of whether we pass anything in (node_modules/victory-native/src/cartesian/CartesianChart.tsx:727-768):

let composed = customGestures ?? Gesture.Race();   // line 727 — empty Race() when we pass nothing
// …
<GestureHandler gesture={composed} dimensions={{x: 0, y: 0, width: …, height: plotBottom}} />

GestureHandler (node_modules/victory-native/src/shared/GestureHandler.tsx) renders <GestureDetector gesture={composed}><Animated.View style={{position:'absolute', …}}/></GestureDetector>. Because we pass nothing, composed is an empty Gesture.Race(), and that inert surface sits directly over every bar, spanning canvas [0,0]…[right, plotBottom]. The outer detector therefore only gets a clean shot at the region Victory's overlay does not cover — the x-axis label strip below plotBottom — which is exactly why label hovers resolve a point while the bars themselves are dead. This is true on the web build (index.tsx/Skia-web) and on native (index.native.tsx), so both platforms are affected.

Proposed fix

Hand our gestures to the surface that actually receives plot-area events — Victory's overlay — instead of fighting it from the outside. Coordinates already line up: the overlay's origin is canvas (0,0), the same frame as setPointPositions' xScale(i)/yScale(value) values, so no hit-test math changes.

Because react-native-gesture-handler forbids reusing one gesture instance across two <GestureDetector>s, split the hook's output into two independent instances — one for the overlay (hover + tap on bars), one hover-only instance for the outer container (so the existing label-strip tooltip behavior survives, and navigation only ever fires once, from the overlay):

// src/components/Charts/hooks/useChartInteractions.ts — replace line 282 and the return block
const plotGestures = Gesture.Race(hoverGesture(), tapGesture()); // overlay: bar hover + tap
const labelGestures = hoverGesture();                            // outer container: label-strip hover only

return {
    plotGestures,
    labelGestures,
    setPointPositions,
    matchedIndex: chartInteractionState.matchedIndex,
    isTooltipActive,
    isCursorOverClickable,
    initialTooltipPosition,
};

// src/components/Charts/BarChart/BarChartContent.tsx
const {plotGestures, labelGestures, setPointPositions, matchedIndex, isTooltipActive, isCursorOverClickable, initialTooltipPosition} =
    useChartInteractions({handlePress: handleBarPress, checkIsOver: checkIsOverBar, isCursorOverLabel, resolveLabelTouchX: findLabelCursorX, chartBottom, yZero});

// …in the return:
<GestureDetector gesture={labelGestures}>
    <Animated.View style={[styles.chartContent, dynamicChartStyle, cursorStyle]} onLayout={handleLayout}>
        {chartWidth > 0 && (
            <CartesianChart
                xKey="x"
                customGestures={plotGestures}   // <-- the fix: our hover+tap now live in Victory's overlay
                padding={chartPadding}
                /* …unchanged… */
            >
                {({points, chartBounds}) => points.y.map((point) => renderBar(point, chartBounds, points.y.length))}
            </CartesianChart>
        )}
        <ChartTooltipLayer /* …unchanged… */ />
    </Animated.View>
</GestureDetector>

LineChartContent.tsx shares the identical structure and bug — apply the same change at src/components/Charts/LineChart/LineChartContent.tsx:156 (hook destructure), :254 (outer <GestureDetector> → labelGestures), and :260 (add customGestures={plotGestures} to <CartesianChart>).

Why this approach

It targets the one element that is guaranteed to receive plot-area pointer events — Victory's own overlay — so the fix holds regardless of the exact propagation quirk (on web, RNGH binds pointerenter/pointerleave, which do not bubble, to each detector's node; the topmost overlay wins the hover, and pointer capture on pointerdown claims the tap). The two-instance split is required by RNGH's "do not share a gesture across detectors" rule and is what lets us keep the deliberate label-strip hover at useChartInteractions.ts:173-180 instead of regressing it. The simpler alternative — passing customGestures to CartesianChart and replacing the outer <GestureDetector> with a plain Animated.View — also makes the bars work, but it silently drops x-axis-label hovers, so it is rejected in favor of preserving existing behavior.