Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
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 http://remysharp.com/doing-it-right-skipping-the-iphone-url-bar/
  • Loading branch information...
commit baa5c6de4f81e54d7bcda80cf07d7403ca311a4e 1 parent c4f8e7d
@remy authored
Showing with 3 additions and 1 deletion.
  1. +3 −1 js/jquery.mobile.init.js
View
4 js/jquery.mobile.init.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.
$(function(){
- 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

@scottjehl

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. https://github.com/remy/jquery-mobile/blob/baa5c6de4f81e54d7bcda80cf07d7403ca311a4e/js/jquery.mobile.init.js#L128

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

@remy
Owner

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

@scottjehl

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;
$window.one( "scrollStart", function(){ userScrolled = true; }
if( !userScrolled ){ $window.load( $.mobile.silentScroll ); }
@remy
Owner

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.
Something went wrong with that request. Please try again.