One of the features I want to implement for Really Simple History 0.8 – based on requests from the RSH Google Group – is automatic updates of the document title. When the hash changes, so will the title, guaranteeing that bookmarks, the history menu and the dropdowns on the back and forward buttons all give relevant information about each discrete page state. Instead of bookmarking a page with a generic title such as "My Email Program," you’ll get something useful, like "My Email Program: Inbox" or "My Email Program: Drafts."
Initial implementation was easy. When you add a history point in RSH, you pass in an optional JSON hash of supplementary data that can be recovered for the duration of that session. This historyData object was the most sensible place to pass in a new document title, so I added a method to inspect the historyData of any given history point, look for a member called newTitle, and dynamically update the title. I also got a little fancy and gave the user the option to set a base title with a replacement parameter so that they didn’t have to keep passing in the name of their website with each history point. The new method looked like this:
changeTitle: function(historyData) {
/*change the document title if called to do so*/
if (historyData && historyData.newTitle) {
/*Plug new title into the base title or use it raw if none is found*/
var winTitle = this.baseTitle
? this.baseTitle.replace(‘@@@’, historyData.newTitle)
: historyData.newTitle
;/*IE history is keyed off the iframe, so we need to update its title, too*/
if (this.isIE) {
this.iframe.contentWindow.document.title = winTitle;
}
document.title = winTitle;
}
},
Then, I just needed to add code to delegate to the new changeTitle method each time a history point was added or a history event fired. The changes to my add method looked like this:
add: function(newLocation, historyData) {
if (this.isSafari) {//EXISTING CODE HERE
this.changeTitle(historyData);
} else {
var that = this;
var addImpl = function() {
//EXISTING CODE HERE
that.changeTitle(historyData);
};/*Now queue up this add request*/
window.setTimeout(addImpl, this.currentWaitTime);/*Indicate that the next request will have to wait for awhile*/
this.currentWaitTime = this.currentWaitTime + this.waitTime;
}
},
The changes to my fireHistoryEvent method looked like this:
fireHistoryEvent: function(newHash) {
var decodedHash = decodeURIComponent(newHash)
/*extract the value from our history storage for this hash*/
var historyData = historyStorage.get(decodedHash);this.changeTitle(historyData);
/*call our listener*/
this.listener.call(null, decodedHash, historyData);
},
Playing around with various test pages and RSH applications, I was happy with my work. Each time I added a history point or clicked the back button, my page title updated to exactly what I wanted it to. Then things got tricky. To put my new method through its paces, I started navigating back and forward through the history stack and inspecting the back and forward dropdowns each time. Things quickly got weird. Page titles that had previously appeared correct in these dropdowns were getting updated with the wrong values. You’d go to a history point with a title such as "Inbox" and instead you’d see the "Drafts" page. It took some playing around, but I finally realized why.
Each time the back or forward button gets clicked, the document title for the page that is coming off of the history stack to become the current document gets reset to the current document title. (This only happens when the history changes involve new hash values on the same base URL.) The document title doesn’t get set when a document moves out of the current document position, but rather when it moves into the current document position.
That’s a real problem for RSH and other history managers. Because RSH is essentially reactive – waiting for history changes to occur via back or forward and then working its magic – there’s no way to change the document title before the history change occurs. So as a page that’s already in the history stack becomes the current page, it gets assigned the the wrong title. This behavior manifests itself a little differently in various browsers – especially IE, whose history-stack page titles get set by a hidden iframe – but it’s an issue in all of them. Setting a title when a history point gets added: no problem. Setting a title after a history change has occurred: too late.
The new feature does get a couple of things right: The title in the browser title bar always reflects the current state of the application, and bookmarks always reflect the correct title. (By the time a user is able to bookmark a page state, the title has already been updated to reflect that state.) Two out of three ain’t bad – right?
I’m a little torn as to where to go from here. Is this really a feature rather than a bug if it improves some aspects of the browsing experience while degrading others? At least when the history stack shows the same document title 10 times in a row, the only sin is a lack of information. With this new feature enabled, the history stack reports wrong information. The user who tries to find a specific page state in the history stack will end up with the wrong place and quickly grow annoyed.
I’ve given some thought about how this state of affairs could be improved, but any potential solutions would vastly complicate the fireHistoryEvent method. You’d have to intercept each history change, change the document title to the correct value, change the hash back to the previous hash so that the correct title would get set in the history stack, then change the hash again. I’ll probably implement this functionality just to see whether it’s possible and how weird the flicker looks in the address bar. But it seems like a lot of extra code – and extra testing – for something that’s not essential to history management.
If any RSH users want to play around with the code and offer solutions, I’m all ears. The provisional changes are part of the latest code in the Google Code SVN repo.
I read your block and definitely you didnt read my code. You cant be before the click event but you can reproduce the action. And then you can change the title on the right moment. As I told you before I already have it up and running without messing up.
document.title = title;
// I change the title and put the same hash again the browser will reset the title again but this time good.
var hash = document.location.hash;
document.location.hash = hash;