If setHash is called, and the resulting changed signal calls replaceHash, then replaceHash replaces the previous history entry instead of the new history entry.
For example: Hash fragment is /, and setHash('/a') is called. Crossroads.js is used to redirect '/a' to '/a/b' (by calling replaceHash). The history after doing this should be '/', '/a/b', but instead, '/' is replaced with '/a/b', so the history is '/a/b', '/a/b'.
It looks like this is caused by setHash and replaceHash updating window.location after calling _registerChange. (setHash's _registerChange triggers replaceHash, and replaceHash replaces window.location before setHash can update window.location.) If they instead updated window.location first, then that would fix this issue (but may raise other issues; I'm not familiar enough with the code and with browser implementations to know).
For now, I'm using this function as a workaround.
function setHashWithPossibleRedirect(hash)
{
var old_hash = window.location.hash.replace(/^#/, '');
hasher.changed.active = false;
hasher.setHash(hash);
hasher.changed.active = true;
hasher.changed.dispatch(hash, old_hash);
}
If setHash is called, and the resulting changed signal calls replaceHash, then replaceHash replaces the previous history entry instead of the new history entry.
For example: Hash fragment is /, and setHash('/a') is called. Crossroads.js is used to redirect '/a' to '/a/b' (by calling replaceHash). The history after doing this should be '/', '/a/b', but instead, '/' is replaced with '/a/b', so the history is '/a/b', '/a/b'.
It looks like this is caused by setHash and replaceHash updating window.location after calling _registerChange. (setHash's _registerChange triggers replaceHash, and replaceHash replaces window.location before setHash can update window.location.) If they instead updated window.location first, then that would fix this issue (but may raise other issues; I'm not familiar enough with the code and with browser implementations to know).
For now, I'm using this function as a workaround.