The associated issue has been closed. If/when that gets re-opened after discussion I'll reopen this pr.

Since we know we're going back through history and that the transition depends on the current active page for it's scrollto position:

active = $.mobile.urlHistory.getActive(),
toScroll = active.lastScroll || $.mobile.defaultHomeScroll,

is there any reason we can't just dictate that before using the history object. Eg:

//if there's a data-rel=back attr, go back in history
if( $link.is( ":jqmData(rel='back')" ) ) {
  urlHistoryStack.getPrev().lastScroll = settings.toPageScrollPosition;
  window.history.back();
  return false;
}

and then allow the transition handler remain the same? I'm just eyeballing it here.

Well, the issue isn't that the lastScroll isn't being set, it's that the call to window.history.back() actually causes the page to jump down to that lastScroll position that is retrieved from the urlHistory record for the page we're transitioning to. This happens before it's supposed to happen (i.e. it should jump down to that lastScroll position AFTER the transition completes, not during the startOut phase of the transition).

The effect is this: click back -> it jumps up to scrollTop before the transitions starts -> then it jumps back down to the lastScroll of the $to page -> then it transitions to the $to page then it jumps down to lastScroll as it should.

@dcarrith

Just to be clear. urlHistory in your description means the browsers history correct? You're saying that the back button recalls the scroll location for that history entry from the browsers internal representation and sets that before the transition logic runs and sets the value as assigned to active.lastScroll?

I'm confused because it also sounds like you're saying that we're doing two scrolls down from the top of the page.

If the former is the case I'm wondering if we can do a comparison and avoid the second scroll when the position "close enough".

I was going on memory. I'll take a look at the code again and get back to you.

@dcarrith

This should have been the first thing that I said, but thanks for taking the time to help out with this issue. If we can make the transitions smoother it would be a big win.

@johnbender - I've become obsessed with tracking down this issue. But, I think I have exhausted all of my troubleshooting energy. I simply can't figure out the source of the jump down to the last scroll position of the page we're going back to.

Here are some of the scenarios I tested and the results. Maybe you or one of the other devs can make some sense out of it.

Just so we're on the same page, the call to window.history.back() is in the block of code on lines 1312 - 1316 of jquery.mobile.navigation.js (however, I also removed this piece from the overall equation and the issue still occurs - see the last section starting with "It's also worth mentioning..." for more info on that scenario).

In my test scenario, I have the main index page, an artists page, and an albums page showing the albums for a particular artist. If I scroll down the list of artists and select one, I get to the albums page. Then, if I click the back button (my own back button or the browser back button) I see a scroll down to the last scroll position of the artists page before the transition even starts.

As a quick test, I also set my default transition to 'none' and confirmed that the issue still occurs.

I also fiddled around with different combinations of the changeHash, hashListeningEnabled and pushStateEnabled settings (set in mobileinit). For example, I tried this combination:

$.mobile.changePage.defaults.changeHash = true;
$.mobile.hashListeningEnabled = false;
$.mobile.pushStateEnabled = false;

The erroneous scroll down to last position of the page we're going back to (artists page) still occurs, and so does the update to the location.hash, but the page doesn't transition to the previous page (because the hash listening is disabled of course).

This is also interesting...Even with $.mobile.minScrollBack set to 1000 in my mobileinit, the erroneous scroll down to last position of the page we're going back to STILL occurs. However, in that case, when it actually transitions back to the artists page, the scrollTo last position does not trigger since the minScrollBack is set so high. This kind of makes me think that the issue lies with jQuery itself, or in the browser (I've tested the latest version of Chrome on OSX as well as Firefox). I have tried console.log'ing the history object right before the call to window.history.back() to see if scroll position is even being tracked by the browser and it is NOT. So, that leads me to believe it might be an issue in the core jQuery library. My step through debug sessions always led me to the core jQuery library but then I always ended up getting lost or my script debug session would freeze up (not sure what's going on there). However, the problematic area seemed to be around line 2940 of jquery-1.7.2.js. I've also tried using jquery-1.7.1 and 1.7.0 but the same issue occurs.

It's also worth mentioning that I am also able to recreate the issue by removing the data-rel="back" attribute from my back button and adding the following event listener for the back button:

$('body').on('click', '#header-back-link', function(evt) {

evt.preventDefault();
evt.stopPropagation();

window.history.back(); // window.history.go(-1); has the same issue

});

If I add this line above the call to window.history.back():

$.mobile.urlHistory.ignoreNextHashChange = true;

The erroneous scroll down to last position of the page we're going back to (artists page) still occurs, and so does the update to the location.hash, but of course, the page doesn't transition to the previous page because the hash change is being ignored.

I'll try to get a video screen capture posted on vimeo so you can see what I'm talking about. I'm curious if anyone has ever noticed this before, or has it just been lumped in with the "jumpy transitions" kind of issues.