- This topic is empty.
March 17, 2015 at 11:13 am #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
bodyis 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);
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
Thanks for the reply, I was thinking the same thing – some self amplifying feedback from scrolling. Very weird, you can divide the var
placementby 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
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.
$('html')because I’m testing in Firefox.March 18, 2015 at 3:44 am #198438
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.March 18, 2015 at 5:51 am #198443
One more addition – plain JS scrollTo() seems to be a bit better here because you don’t have to make a distinction between
bodythen. Still weird behaviour though.March 18, 2015 at 8:24 am #198459
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
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.