The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums JavaScript Scrolltop inexplicably going haywire

  • This topic is empty.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #198387

    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).


    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.


    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


    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


    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.


    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.

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

Viewing 6 posts - 1 through 6 (of 6 total)
  • The forum ‘JavaScript’ is closed to new topics and replies.