[Bug]: The padding of PaperScroller's "scrollWhileDragging" is measuring incorrectly the position of the cursor (part 2)

[alexandernst]

What happened?

This is an issue closely related to #1779 (which I opened last year), hence I'll use the code that I provided there.

I found out that if the paperscroller is zoomed, the padding that is used to trigger the scrollWhileDragging feature is wrongly calculated.

If I set the zoom to 0, the scrolling starts once the cursor surpasses the red border:

Grabacion.de.pantalla.2023-08-20.a.las.12.41.59.mov

But if I set the zoom to '1.5', the padding is wrongly calculated and the scrolling starts way before the cursor has reached the red border:

Grabacion.de.pantalla.2023-08-20.a.las.12.43.31.mov

Code with the poc: https://codesandbox.io/s/rappid-paperscroller-bug-zoom-z4zdqf

Version

3.7.5

What browsers are you seeing the problem on?

Firefox, Chrome, Safari

What operating system are you seeing the problem on?

Mac

[kumilingus]

I don't think it's a bug. The padding that the user sets is defined in the graph dimensions.

It's something you might want. Consider a situation where your graph contains 100x100 rectangles and you want it to start scrolling when the rectangle touches the border, i.e. set padding to 50 and it will work no matter what the current zoom level is set to.

I can also see why this might be undesirable behavior. I would suggest adding a new option paddingUnits.

type paddingUnits = 'local' | 'client';

[alexandernst]

🤔 I don’t see how that (your example) would play in the real world. Even if I had a 100x100 graph and I wanted the scrolling to start at the border, if my user zoomed in the paper, he’d get the same behavior that I described in my previous post, which is not usable at all. Maybe somebody will find a use case in which that is the desired behavior, so I do agree that a paddingUnits option should be added, but imho it should default to client.