Dynamically mounting Joyride causes scrolling even if scrolling is disabled in props

[MikeShi42]

🐛 Bug Report

I'm attempting to use multiple Joyrides on a single long page, I found initially that Joyride seems to get confused between multiple instances and will scroll between steps between multiple instances of Joyride.

I've tried to overcome this by dynamically mounting Joyride if the component is within View so that only one Joyride is active at a time, however it seems like the component when mounted dynamically will always scroll to focus on Joyride, even if I ask it not to via props.

Even with disabling scrolling via all the props available:

{isInView && (
<Joyride
    ...
    continuous
    disableScrolling={true}
    disableScrollParentFix={true}
    scrollToFirstStep={false}
    debug={true}
    disableOverlay
    scrollDuration={-1}
  />
)}

the component will continue to scroll.

I've chased it down to Scope being called to set focus, likely here: https://github.com/gilbarbara/react-joyride/blob/main/src/components/Step.js#L206.

To Reproduce

Dynamically mount Joyride with scrolling disabled, observe that Joyride still will scroll the page to the tooltip when first mounted.

Expected behavior

Joyride should not do anything with scrolling at all (even if it's via focus) when scrolling is disabled via props.

Link to repl or repo (highly encouraged)

Please provide a https://codesandbox.io/ demo or similar.

Issues without a reproduction link are likely to stall.

Run npx envinfo --system --binaries --npmPackages react-joyride

Paste the results here:

  System:
    OS: macOS 12.3.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 144.55 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.18 - ~/.nvm/versions/node/v16.13.0/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
  npmPackages:
    react-joyride: ^2.5.0 => 2.5.0 

[gilbarbara]

Hey @MikeShi42

The button focus is for accessibility; without it, screen readers won't be able to navigate the tour. The page will only scroll if the tooltip is outside the viewport. Is that the case?

Anyway, changing the Scope class isn't a good choice for this. If you have another approach, let me know.

[MikeShi42]

Yes if the toolitp is outside of the viewport it'll cause scrolling. My use case is a bit unconventional with a long scrolling page with multiple Joyride instances throughout in the page. I'm wondering still if there's possibly an escape hatch users can specify to completely eliminate Joyride's ability to control scrolling (including the current focus mechanism).

I'm not too familiar with needing to set focus for accessibility reasons, is it because Joyride wouldn't have the right level of focus for screen readers otherwise? (Since it's usually an overlay on an application?) If so, in at least the use case I'm using, Joyride is not a "forced" overlay as much as just a helper tooltip over the existing UI, but the user is expected to be able to interact with the underlying app without even touching the tooltips. So perhaps the accessibility issue isn't as big of a deal (unless the button is literally unaccessible I guess otherwise)

[gilbarbara]

Maybe using preventScroll in the focus call is a better choice?

[JoeyAtSS]

I have the opposite effect, dynamic loading causes scroll not to work. My app have a few widgets in the home screen. So i have a {WidgetsReady && <Joyride..../>}, this is because i dont want the tour to start when the widgets aren't loaded yet.

I even tried <Joyride run={widgetsReady} .../>, but it still wont scroll... any idea why? @gilbarbara @MikeShi42