Call to window.history.back() in click handler of jquery.mobile.navigation.js causes jump down to lastScroll of $to page if going back
Closed this issue · 6 comments
As stated in the title of the issue, there is a call to window.history.back() in the click handler of jquery.mobile.navigation.js that causes a jump down to lastScroll of $to page AFTER the scrollTo top occurs before the startOut phase of the transition. This is one of the contributing factors to the jumpiness that is particularly noticeable on Android.
I have been using a fix I came up with for a while now without any issues. I'll be submitting a pull request either today or tomorrow for review. It passes all the automated tests, but may cause an issue on certain older platforms that I don't have access to in order to test.
I've mentioned this in other issues suggesting we should avoid the history object for these cases but I'll repeat here as well:
The problem with altering our using of back is that we have to handle backwards traversal in history via the back button anyhow so the addition of logic to the click handler solves less than 50% of the cases and adds additional complexity in and already over complex module (navigation).
If there's a solution that resolves this issue in both cases I'm all ears but otherwise we need to use the history object for consistency.
I'm going to close this issue but I'm open to discussion.
Associated PR for further discussion: #4543
@johnbender: thanks for the feedback. I guess I was looking at it the other way...you're already tracking history in urlHistory. So, why not use it in place of window.history.back() since it can solve part of the larger issue (jumpiness) that is probably one of the top reported issues for Android.
"...the addition of logic to the click handler solves less than 50% of the cases and adds additional complexity in [an] already over complex module"
Can you elaborate on that statement? What do you mean by "less than 50% of the cases"?
Similarly, I'm not sure what you're referring to when you say "a solution that resolves this issue in both cases". What test cases (both) are you talking about?
Personally, I prefer to fix issues even if it means adding a little complexity to the code base.
Android devs (as an example group) don't make use of explicit back buttons and google actually counsels developers to omit them from their applications in preference to the hardware back button. In the browser, that means supporting a hash change back through history without any reference to where the event came from. So my totally arbitrary estimation of 50% is meant to capture an enormous set of use cases where this issue will still exist because going back through history happens frequently without an explicit addition of the back button.
Therein lies my interest in a more general solution that prevents us from special casing our back buttons which adds not only code but a requirement for "code base" knowledge when dealing with back buttons. That is, with your proposed/pullrequest you need to know how the framework behaves when someone creates a data-rel=back link and also how it behaves when someone hits the back button.
All that said, I agree with your closing statement. If we can't come up with a way to handle this is both cases then might just need to eat the extra complexity in the interest of improving explicitly included back buttons.
Fair enough. I'll see if I can come up with a more general solution. Thanks for the explanation.
I've also commented on the PR. If we can simplify the code change I'd be a lot more excited about testing it to see if it fixes this issue.