Basically you have two history "pots" you need to tamper with. Browser and JQM.
JQM urlHistory
You can modify JQMs urlHistory very easily. From the JQM code:
urlHistory = {
// Array of pages that are visited during a single page load.
// Each has a url and optional transition, title, and pageUrl
// (which represents the file path, in cases where URL is obscured, such as dialogs)
stack: [],
// maintain an index number for the active page in the stack
activeIndex: 0,
// get active
getActive: function () {
return urlHistory.stack[urlHistory.activeIndex];
},
getPrev: function () {
return urlHistory.stack[urlHistory.activeIndex - 1];
},
getNext: function () {
return urlHistory.stack[urlHistory.activeIndex + 1];
},
// addNew is used whenever a new page is added
addNew: function (url, transition, title, pageUrl, role) {
// if there's forward history, wipe it
if (urlHistory.getNext()) {
urlHistory.clearForward();
}
urlHistory.stack.push({
url: url,
transition: transition,
title: title,
pageUrl: pageUrl,
role: role
});
urlHistory.activeIndex = urlHistory.stack.length - 1;
},
//wipe urls ahead of active index
clearForward: function () {
urlHistory.stack = urlHistory.stack.slice(0, urlHistory.activeIndex + 1);
}
};
So all of the above functions are available and can be called like this for example:
$.mobile.urlHistory.clearForward();
To monitor your history, put this somewhere and listen for pageChange (once transitions are done) to see what is inside the urlHistory:
$(document).on('pagechange', 'div:jqmData(role="page")', function(){
console.log($.mobile.urlHistory.stack);
});
From there you can start to see what should be in the history and clean it up as you need.
I'm using this a lot for my own navigation layer to modify what is stored in the urlHistory and what should not be stored. Sync-ing with the browser is the difficult part...
On sync-ing with the browser:
In my navigation layer I'm only removing double entries from the urlHistory, so there is always a page to go to (and not two), when you click the browser back button. In your case, you will presumable have 4 entries in the browser history, but if you remove 2 entries from JQM urlHistory, you will have two pages "not to got to" when the back button is clicked. So if your browser history looks like this:
www.google.com
www.somePage.com
www.YOUR_APP.com = page1
page2
page3
page4
And your remove page2 and page3, clicking back-button should result in:
1st back-click = page4 > page1
2nd back-click = page1 > www.somePage.com [because you removed page3]
3rd back-click = www.somePage.com > www.google.com [because you removed page2]
A theoretical workaround would be:
- keep a counter how "deep" you go into a page
- remove pages from JQM urlHistory and get a "jump" value = counter-removedPages
- on next browser back click, do jump x window.history(back) and only let one JQM transition pass. You url will unwind page4>page3>page2>page1 in one step and you only allow JQM to do a single transition from page4 to page1
- check what's in the urlHistory and clean up after your "triple back"
Beware this is not an optimal solution and you have to consider a lot of things (user clicks somewhere else before going back etc). I tried forever to get something like this to work in a more complicated setup and eventually just stopped using it, because it never worked as it should. But for a simpler setup it may very well work.
