Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with bounce #1

Open
joelambert opened this issue Oct 16, 2011 · 9 comments
Open

Problem with bounce #1

joelambert opened this issue Oct 16, 2011 · 9 comments

Comments

@joelambert
Copy link
Owner

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.

@cubiq
Copy link

cubiq commented Oct 16, 2011

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.

@joelambert
Copy link
Owner Author

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 Spinellireply@reply.github.com 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:
#1 (comment)

@jordwalke
Copy link

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.

@freddywang
Copy link

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

@jordwalke
Copy link

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

@freddywang
Copy link

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

@savitasingh
Copy link

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.

@joelambert
Copy link
Owner Author

@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);

@Noitidart
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants