Browse files

fix for scrolling the window when the user has already started scroll…

…ing - apparent when slow download and user is ahead of content or when jQM is being used on desktop platform - ref
  • Loading branch information...
1 parent c4f8e7d commit baa5c6de4f81e54d7bcda80cf07d7403ca311a4e @remy committed Jul 17, 2011
Showing with 3 additions and 1 deletion.
  1. +3 −1 js/
4 js/
@@ -111,7 +111,9 @@
//then check what the scroll top is. Android will report 0... others 1
//note that this initial scroll won't hide the address bar. It's just for the check.
- window.scrollTo( 0, 1 );
+ //don't scroll if the user has already scrolled the device, particularly visible when jQM
+ //being used on a desktop browser
+ if (!window.pageYOffset) window.scrollTo( 0, 1 );
//if defaultHomeScroll hasn't been set yet, see if scrollTop is 1
//it should be 1 in most browsers, but android treats 1 as 0 (for hiding addr bar)

4 comments on commit baa5c6d


thanks, Remy. This is a good idea for sure.

I'm not sure if the change covers it completely though, does it? The first time we call scrollTo is purely for going to 1px and then checking what the scrollTop is. Android will report 0, whereas every other browser will report 1. If it's 1, we then scroll to 0 when onload fires, and any subsequent time we scroll to "top".

Anyway, I think your qualifier also needs to be added to the silentScroll call that's further down as well. I think wrapping this whole line with the same condition should do it.

The other thing is that scrollTop is reported differently depending on the browser (right?). $.support.scrollTop is the support test, and $(window).scrollTop() will normalize the lookup and avoid errors in Symbian browsers as well (which was an issue in jQM in the past).

lemme know if this makes sense! Thanks for the idea :)


Shitbeans - you're right - and I think I was thinking something similar a few minutes ago. Basically, it's after the images load, not when the DOM is ready - so yep - this change can be canned. But you, like you said, need to check for the current offset before scrolling the device.

I don't think the check should be simply moved down, but actually put inside the window.ready event handler and at that point check the offset.

I don't know enough about Symbian mobile scrollTop support to say if you're wrong - you're definitely the pros here - so if you need to test support and then value - or if the value just reports 0 either way, you're a step towards it being right :)


Ah ok, so the domready one will always fire before the user is able to scroll anyway I guess? Sounds right. Just need to qualify the silentScroll line with scrollTop check then I guess...
I think something like this will do? (ln 128)

if( $window.scrollTop() > 1 ){ $window.load( $.mobile.silentScroll ); }

Alternatively, maybe we could avoid a call to scrollTop (which I believe triggers a reflow) by setting a flag if a scroll happens between domready and load?

var userScrolled;
$ "scrollStart", function(){ userScrolled = true; }
if( !userScrolled ){ $window.load( $.mobile.silentScroll ); }

Looks right, except you want the if (!userScrolled) inside the window.onload event handler - because the user it likely to scroll between the DOM loading and the images loading. Whereas the user is unlikely to have scrolled before the DOM has loaded.

Please sign in to comment.