- Fixed a bug in the hashchange handler for the pushstate/replacestate plugin that was incorrectly resolving hashchanges for ids against the current location.href, which could be a different document. We now resolve id hashes against the document URL.
- Modified changePage() so that it sets the settings.dataUrl option to the documentUrl, when navigating to the first-page of the application document. This prevents any id on the first-page from being added to the location hash. This means that URLs that used to be produced like this:
http://site.com/apps/#first-page-id
will now display as:
http://site.com/apps/
Developers that wish to get the old behavior back can register a pagebeforechange handler and do something like this:
$( document ).bind( "pagebeforechange", function( e, data ) {
var toPage = data.toPage;
if ( typeof toPage === "object" && !data.options.dataUrl && toPage[ 0 ] === $.mobile.firstPage[ 0 ] && toPage[ 0 ].id ) {
data.options.dataUrl = "#" + toPage[ 0 ].id;
}
});
The handler above will make sure that any page changes to the first-page will always display as:
http://site.com/apps/#first-page-id
- Make sure that our hashchange resolves non-path hashes against the documentBase. This prevents the resulting changePath() call from incorrectly resolving against the URL for the current active (external) page.
- Fixed a problem in the push-state code. A hashchange event is *NOT* fired when navigating back (window.history.back()) from an external page to an internal page. This makes sense when you think about it since hashchange is only ever fired when the hash of the current document url changes, not when the document url itself changes. The fix was to make sure that the pushstate hashchange callback always sets a state object, even on embedded page URLs. This allows the hashchange callback to be triggered from within onPopState().
