Fix for Bug #1988 - Don't rely on history.back() for back buttons

[adambiggs]

This works in my testing and fixes the BB5 history.back() bug. Also might be other benefits to exposing $.mobile.prevPage.

[toddparker]

Thanks Adam - we'll take a look soon.

[scottjehl]

Thanks Adam.

I have a few questions regarding this pull, as I'm not sure I understand how it addresses the issue. Doesn't BB5 get a new page reload for every page change (opted out of ajax)? If so, how does using changePage in this way address that issue? Does the device's native back button share the problem outlined in the bug or is it that history.back() is not supported? Is this just a bug when using phonegap in BB5 or on the web too?

I'm also concerned that this change creates a separation in all browsers (not just BB5) between the real browser history stack and our internal history stack as well, in that it will always add a forward history entry when it should be removing one upon navigating backwards (popping the active page off the stack). Essentially, after using the custom back button with this logic in place, clicking my browser's back button would actually take me "forward" to the page I just clicked "back" from, from a user's perspective.

We'll review this more tomorrow; please chime in if you have any insight on these points.

Thanks again, Adam!

[adambiggs]

@scottjehl

I hadn't thought of the history issues you pointed out. I'm using jQM primarily inside PhoneGap so the browser back/forward buttons aren't an issue for me (I've disabled the hardware back button in Android for all my PG projects). I'm guessing this fix might only be useful in my specific scenario.

I'm using jQM in multi-page mode, so all my pages are in a single index.html file in my PhoneGap project. In this scenario data-rel="back" buttons are all broken in BB5. They simply do nothing, possibly because there's no previous page in the history stack. On the web when navigating pages in a multi-page setup, if you click the BB5 back button, you're returned to the last "real" page you visited. Any multi-page pages navigated aren't remembered.

Hope this helps.

[scottjehl]

Yeah, that sounds consistent with how BB5's history is set up, in that hash changes do not create history entries, so one click on the back button sends the user back to a previous site. Unfortunately, this solution will break how the framework is expected to work in browsers that do get hash-based history correct, whereas browsers that get it wrong are relatively few: mainly BB5 and Symbian.

I think your best bet here is to create a global navigation that can always work in a reliable way, instead of using the framework-injected back buttons. We've actually been recommending this recently to developers anyway, which is why back buttons are disabled by default now. We've also been trying to steer developers away from single-page sites in general, since among other reasons, there won't be a way to fully support them with the browser's history in BB5.

I'm going to close this out, but I'd encourage you to keep using it for your app if it works for your purposes.
Thanks again, Adam!