spotlightClicks fails for targets within scrollable containers on @next branch

[yuvalkarmi]

Hey @gilbarbara,

First off, huge thanks for creating and maintaining react-joyride - it's an incredibly useful library!

I wanted to report a potential issue I ran into while using the next branch (^3.0.0-7).

🐛 Bug Report

On the @next branch (^3.0.0-7), when using spotlightClicks: true for a step targeting an element inside a scrollable container (e.g., div with overflow-y: auto), clicks on the highlighted target element are blocked by the overlay. (I tested this with disableOverlayClose={true} is set on the <Joyride> component). The click does not propagate to the underlying target element.

To Reproduce

Steps to reproduce the behavior:

1. Open the CodeSandbox demo linked below (uses react-joyride@^3.0.0-7).
2. Click the "Start Tour" button.
3. Scroll inside the light blue bordered box (the scrollable container) down until the red "Click Me (Target)" button is clearly visible within the spotlight.
4. Try clicking directly on the red "Click Me (Target)" button.

Actual behavior

The click appears to be intercepted by the Joyride overlay. The red target button's onClick handler is not triggered, and the expected alert does not appear.

Expected behavior

The click should register on the target button because spotlightClicks: true is enabled for the step. The button's onClick handler should fire (triggering an alert in the demo).

Link to Codesandbox

https://codesandbox.io/p/sandbox/9lmqzq

Possible Cause (My best guess)

Digging through the code (specifically around the handleMouseMove logic in v3), it looks like the calculation to determine if the user's mouse cursor is currently over the spotlighted target element might be incorrect when that element is inside a scrolled container. The coordinates being compared (mouse position vs. target bounds) might not align correctly after the intermediate container scrolls. useMemo on spotlightStyles in Overlay.tsx in causes an issue:
spotlightStyles was previously calculated in realtime in 2.7.2, but that's no longer the case with useMemo. As a consequence, the overlay's pointer-events style isn't correctly switched to none when hovering over the target, thus blocking the click.

Additional Context

• This behavior seems specific to the next/v3 branch. If you take the exact same CodeSandbox and change the react-joyride dependency back to 2.7.2, the spotlightClicks feature works correctly in the scrollable container. This strongly suggests a change between v2.7.2 and the next branch related to event handling or coordinate calculation within scrolled containers.
• On a personal note, I can't downgrade to v2 because I use React 19

Thanks again for your work on this library! Let me know if any more information would be helpful.

[yuvalkarmi]

Back to add details after digging into the code further. tl;dr: it's because of the useMemo of spotlightStyles in Overlay.tsx.

I had AI draft the explanation, but I confirmed that when changing one of the values the useMemo depends on after the tooltip is shown, the issue is fixed since the styles are then recalculated:

The key difference seems to be how spotlightStyles gets its values:

• v2.7.2 (Class version): The spotlightStyles was a class getter (get spotlightStyles()). This meant every time handleMouseMove needed the styles (like top, left, height, width), the getter function ran right then. It called things like getElementPosition and getClientRect fresh each time, getting the current position of the target, even after scrolling happened.
• v3.0.0-7 (@next - Hooks version): Now, spotlightStyles uses useMemo. This is great for performance, but it only recalculates when its specific dependencies change ([disableScrollParentFix, showSpotlight, spotlightClicks, spotlightPadding, styles.spotlight, styles.spotlightLegacy, target]). The problem is, the scroll position of that intermediate container isn't one of those dependencies.

How that difference causes the issue:

1. When you scroll the container (div with overflow: auto), the target button visually moves on the screen.
2. In v2.7.2, the next time your mouse moved, handleMouseMove asked for spotlightStyles, the getter ran again, got the new top and left based on the scrolled position, and the hover comparison worked with fresh coordinates.
3. In v3.0.0-7 (@next), when your mouse moves after scrolling, handleMouseMove runs, but the useMemo for spotlightStyles doesn't re-run because none of its dependencies changed just from scrolling. So, handleMouseMove gets stale top and left values from before the scroll happened.
4. It then compares your current mouse position (event.pageY/pageX) against those old spotlight coordinates. Since the visual position of the spotlight changed with the scroll, but the coordinates used for the check didn't, the comparison fails.

Why clicks get blocked (pointerEvents):

Because that comparison uses the stale coordinates, the code incorrectly thinks your mouse isn't over the spotlight (inSpotlight becomes false), even when it visually is. This stops the mouseOverSpotlight state from becoming true. As a result, the overlay style keeps pointerEvents: 'auto', which blocks your click from ever reaching the button underneath.

[yuvalkarmi]

Alright screw it, I just resolved it myself haha. @gilbarbara if this seems like a reasonable fix, then please merge. My rationale is that it's okay to calculate styles once for render, which may or may not correspond to a mouse move, and once whenever the mouse moves (the calculations are fairly cheap).