Plot & page scrolling

[alexcjohnson]

We've got a whole bunch of open issues related to scrolling, and I was about to make a new one about trying to detect when a scroll came from outside our plot - feels like we need a coherent strategy for addressing them all, or at least they should all be considered when trying to fix the others.

Open issues:

• No way to disable mouse-scroll zoom for geo subplots #143, scatter3d zooms on scroll even if zoomScroll is false #2998 - 3D and geo (and mapbox) plots hijack page scroll regardless of config.scrollZoom - done in: Make scrollZoom config option a flaglist #3422
• Consider and possibly put in place a common, unified scroller solution #2054 - we have 3 different scrollbar implementations, merge them
• scrollZoom no longer works when page is scrollable #2371 - browser/OS-dependent bug disabling of config.scrollZoom fixed in: Do not disable scrollZoom scroll{Width,Height} > client{Width,Height} #3424
• Plotly on Mobile - page scrolling #2844 - mobile drag-scrolling has often undesirable consequences
• Plotly table hijacks page scrolling #3249 - table hijacks page scroll even when it's done or has no scroll of its own
  (did I miss any?) - done in: Table scroll #3327

And the piece I'd like to add: On a scrollable page you can end up with your mouse over a scrollable (or scroll-zoom-enabled) plotly element just by scrolling the page without moving the mouse, then our element takes over the scroll events. This means for example:

• On a long page with a plot somewhere on it, you can be scrolling the page and then suddenly find yourself looking at a blank plot because you scrolled to zoom it out before you even had a chance to see it.
• On a page dense with plots (like a dashboard) it's hard to scroll at all - you have to squeeze your pointer over to the margin, or to the gutter between plots.

Proposal: what if we ignore scroll events on any element whose most recent mouseover event is not followed by a mousemove? Then you could confidently scroll a long page without worrying that somewhere in the middle your scroll will be hijacked by a plot, but then as soon as you move the mouse while it's over the plot, you've "engaged" with it and we pay attention to scroll. Of course it's not foolproof, it's easy to unintentionally create a small mousemove, especially with two-finger trackpad scrolling; we could imagine giving this effect a little slop using event.movement(X|Y) though this isn't supported in all browsers, so the solution had better work when that's missing.
Exploratory codepen just to verify what events happen when: https://codepen.io/alexcjohnson/pen/gQRyMb?editors=1011

This would only help partially for the dense dashboard case, you'd just need to make sure your pointer is over a non-scrollable item at the beginning of the scroll, not during the entire scroll.

I can't think of a way to extend this idea to touch...

If we were to do this, it would need to apply everywhere we use the scroll event - all subplot types, all components (cc #2054).

[etpinard]

Potential inspiration: cytoscape/cytoscape.js#695

[etpinard]

From @arthurgailes in #4320

---

Hello,

I've created a plotly graph that has a dropdown too long to be contained in the graph dimensions. Fortunately, the dropdown has a scrollbar for that. Unfortunately, the menu can't scroll with a trackpad or mouse scrollball - the parent page scrolls up and down instead.

See here for an example: https://plot.ly/dashboard/jackp:17487/view#/

The bar itself works, but it's so small I'm worried my users won't even notice it. Is there a solution to either make the dropdown scroll function better or to make the scrollbar itself more noticeable?

Thank you!

[mariahelmrich]

Unfortunately, the menu can't scroll with a trackpad or mouse scrollball - the parent page scrolls up and down instead.

Hi @arthurgailes, @etpinard,

I'm having this same issue. I can't seem to find a solution to this yet. Did you find a fix for this?

Thanks!

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson