ScrollFix icon indicating copy to clipboard operation
ScrollFix copied to clipboard

Problem with bounce

Open joelambert opened this issue 13 years ago • 9 comments

Attempting a scroll when the scrolling section is rubber banding will cause the page to be moved rather that just the desired section.

I've been debugging with Weinre (http://debug.phonegap.com) and it appears that the scrollTop value is not correct when a bounce is happening. This might just be a throttled/network issue with Weinre but I suspect the rate at which the value is updated in the DOM isn't quick enough for our needs.

An example, scrolling to the top:

Start scroll: scrollTop = 386 Touch during rubber banding: scrollTop = 127 (should be < 0!)

I've also tried monitoring the scroll event to see if we can keep track of when the section is 'rubber banding' but it appears that, again, events are not fired quickly enough to reliably capture the rubber banding phase.

joelambert avatar Oct 16 '11 14:10 joelambert

The scrollTop value is not updated at all during bounce. Actually nothing is updated during the rubber band effect (scroll event, checking element position with elementfrompoint, scrolltop, etc...). The DOM is exposed again to the JS once the bounce is over. This means that we cannot even use a setInverval/timeout. I believe that we are pretty much screwed up on this.

cubiq avatar Oct 16 '11 14:10 cubiq

I think you're right.

I can see why scrolling has been implemented in this way as it prevents some problems with traditional websites on the iPhone

I think we need to push for a new CSS property which prevents the scroll event being passed up the DOM tree. I think then it's safer as dev's would have to opt into the behaviour, making Safari safely backwards compatible with traditional websites but also providing the functionality we actually want for web apps!

On 16 Oct 2011, at 15:31, Matteo [email protected] wrote:

The scrollTop value is not updated at all during bounce. Actually nothing is updated during the rubber band effect (scroll event, checking element position with elementfrompoint, scrolltop, etc...). The DOM is exposed again to the JS once the bounce is over. This means that we cannot even use a setInverval/timeout. I believe that we are pretty much screwed up on this.

Reply to this email directly or view it on GitHub: https://github.com/joelambert/ScrollFix/issues/1#issuecomment-2421167

joelambert avatar Oct 16 '11 14:10 joelambert

You'll also notice that during "hyperscrolling" mode - when flicking several subsequent times the scrolling is brought to a very fast speed, the scrolling advances very quickly and blocks basically all javascript from running - setTimeouts, ontouchmove etc. (Or at least it's very significantly throttled). I hope they fix this issue too.

jordwalke avatar Nov 19 '11 07:11 jordwalke

@jordow Actually it doesn't block any js timeout/interval. What I found out, when scrolling inertia kicks in, any scrollTop, offsetTop value of any DOM element is not getting updated. What you get is the value of scrollTop/offsetTop when touchend happened.

freddywang avatar Oct 01 '12 01:10 freddywang

@freddywang: I believe that behavior is the behavior of Safari in iOS 5, and what I described was how iOS4 behaved. Not that either behavior is anything short of extremely disappointing.

jordwalke avatar Oct 01 '12 03:10 jordwalke

@jordow Yup, there is no way we can change the behavior of the iOS scrolling bounce at the moment. I was trying to add the remark that iOS native scrolling doesn't stop any js execution.

I was doing this lazy loading script by detecting scroll event. What I found out is that scroll event was triggered constantly, no significant throttling. I initially suspected that event callback wasn't fired at all, some sort of js execution blockings to be the main culprit. It turned out not the case. Instead, I found out that all the scroll offset/position units weren't updated properly at the time of query until the bounce/inertia scroll stopped. Hence, any setInterval callback that I fired was practically useless as detection failed to determine the correct scroll offset to load the images at the corresponding scroll position.

freddywang avatar Oct 01 '12 04:10 freddywang

I am facing a problem with my Custom jQuery build Popups. I am giving a class “.scrollable” to the div “content” of my popup using the "scrollfix.js". The 1st popup gets the scroll. But the 2nd Popup does not. When I browse it in iPad, using a “weinre” remote debugging tool, it seems that it has got the class “.scrollable”. But there’s no scroll applied. Another thing, I noticed is that when I change the orientation from landscape to portrait & vice versa with my popup open. The popup gets the scroll. Can u please put a light on this..?? Like where I am exactly going wrong?? Thanks in advance.

savitasingh avatar Nov 10 '12 07:11 savitasingh

@savitasingh I suspect that you're adding the elements to the DOM after the scrollfix init code has run, which is why the change in orientation fixes the issue.

You'll need to run this code for all new elements added to the DOM:

var scrollable = document.getElementById("scrollable");
new ScrollFix(scrollable);

joelambert avatar Nov 12 '12 11:11 joelambert

What is the solution for today? This still happens on my full screen web app. I don't want the scroll getting passed up.

Attn @iyzo @1yzo

Noitidart avatar Jun 14 '18 08:06 Noitidart