Scrolltop inexplicably going haywire - CSS-Tricks

This topic is empty.

Viewing 6 posts - 1 through 6 (of 6 total)

Author

Posts
March 17, 2015 at 11:13 am #198387
Shikkediel
Participant
Trying to make a custom scrollbar, there is this issue I came across that makes no sense. I made a draggable handle – it’s offset to the top of the scrollbar is simply calculated to translate that into actual page offset with scrollTop(). Overflow on body is hidden to hide the original scrollbar.

But when the handle is dragged, the page scrolls way too fast and even influences the position of the handle itself. What I mostly don’t get is that instead of scrolling the page down, moving the body up works fine. One can try by using either of these lines in the script (at the bottom) :
```
$('html, body').scrollTop(placement);
// $('body').css('top', -placement);
```
Reduced case on Codepen

First one goes berserk, second one acts as intended. Anyone have an insight to what might be causing this? Thanks in advance.

Edit – one more oddity would be that using scrollTop also works fine when it’s not in any way interacting with the mousemove. When the line is inside the mouseup function, it positions correctly (but that’s obviously not a desired functionality).
March 17, 2015 at 2:26 pm #198409
Shikkediel
Participant
Thanks for the reply, I was thinking the same thing – some self amplifying feedback from scrolling. Very weird, you can divide the var placement by a virtually infinite number and the handle will start moving normally. The larger that number is made, the less the page will actually scroll of course.

Most baffling is how scrolling would change the value of the variable put (position of the handle). It is only dependent on user action and more so, it’s parent has fixed position so scrolling shouldn’t even affect it.

Edit – the only logical reasoning I think could be that scrollTop is amplifying mousemove. How exactly… that’s another thing.

It seems to be indeed the case – if this line is changed to divide mousemove by scrollTop, it takes a day to scroll down but the position is correct :
```
var separation = (finish-begin)/$('html').scrollTop()+1;
```
Added +1 otherwise it would be dividing by zero at the top.
Used $('html') because I’m testing in Firefox.
March 18, 2015 at 3:44 am #198438

Shikkediel
Participant

Sort of found a workaround – subtracting scrollTop from the mousemove. Don’t ask why this works… it’s also leading to new trouble that would need to be solved but it was mostly about getting behind what’s going on. In practice, offsetting <body> in the opposite direction has many advantages over this approach.

Revised pen

March 18, 2015 at 5:51 am #198443

Shikkediel
Participant

One more addition – plain JS scrollTo() seems to be a bit better here because you don’t have to make a distinction between html and body then. Still weird behaviour though.

Why not another pen

March 18, 2015 at 8:24 am #198459

Shikkediel
Participant

Thanks for the analysis, sounds quite logical when you put it like that. Odd thing to come across though.

Kinda wondering if it has the same effect on touch devices. If anyone would care to check that would be much appreciated.

July 22, 2015 at 2:01 pm #205381

Shikkediel
Participant

I found another clue and may have to investigate further soon :

pageY = The y coordinate of the touch point relative to the top edge of the viewport, including scroll offsets.

http://www.javascriptkit.com/javatutors/touchevents.shtml

I think I’m gonna need to use clientY inside the mousemove.
Author

Posts

Viewing 6 posts - 1 through 6 (of 6 total)

The forum ‘JavaScript’ is closed to new topics and replies.