PageContainer "ChangeHash: false" updates browser history

PageContainer "ChangeHash: false" updates browser history

As a newbie to JQM Page Container, I am wondering if my understanding of this feature is incorrect. Please help.

I am using the foll code in JQM 1.4.5 with Apache Cordova:

$(":mobile-pagecontainer").pagecontainer("change", CurentPageUrlWithSuitableQueryString, { allowSamePageTransition: true, changeHash: false, transition: "slide", type: "post" } );

In my code, On clicking any collapsible Divider on the displayed page, I go to JQuery (and via above code ), I go again to the current page with a suitable querystring (based on the clicked Collapsible Divider) and get the corresponding content (for the clicked Collapsible Divider) and display it in the same page.

In this process, I do not want the browser history to be updated because the back button should take the User to the Original Previous Page, and NOT the Pages corresponding to the various Dividers, the User may have viewed.

So I have used the option changeHash: false, assuming the Browser history will not be updated during these many Divider views in the same page.

Everything works perfectly, EXCEPT that I find the Browser History is getting updated and the Back Button does not go to the original previous page; and instead the User has to skip so many pseudo-previous pages (in the history) to get back to the original previous page.

The JQM Documentation says:

The pagecontainer will navigate to the desired page without creating a new browser history entry. The desired page replaces the current page, and the browser's "Back" and "Forward" buttons cannot be used to navigate between the source page and the destination page.

I will appreciate JQM experts helping me out to achieve my goal. Thanks.

Note: BTW, just FYI I am following the above logic because: in view of many Dividers with varying contents(users may view any few of them), getting all info together takes significant perceptible time (at least 7 to 8 seconds) in JQM, frustrating the Users. By the above logic getting the required Divider-content takes only between 1 to 3 seconds based on content; and it does not irritate the users. Hence this approach.