How does Gmail handle back/forward in rich JavaScript?

Question

Gmail seems to have some clever way of handling the back/forward buttons in a rich JS application.

In my organisation we trialled the jQuery history plugin. The plugin basically runs a function every 100ms which parses the URL and tests if it has changed. The history is tracked by HTTP anchors, and if the anchor has changed then the plugin calls a user-specified callback, passing in the new anchor, so that the page can perform custom behaviour to load in the new content.

My organisation determined that the jQuery history plugin was not production quality. I don't blame them to be honest, because you don't really want to force your users' browsers to run a function every 100ms. Also, it made the JS code almost impossible to debug, because clicking "Break On Next" in Firebug or similar JS debugger, would always trap the jQuery history event, and no other events would get a look in.

So we gave up at this point on implementing back/forward functionality in the browser. However, I've recently noticed that Gmail implements this rather nicely. It also uses the HTTP anchor value, but I pressed "Break On Next" and Gmail doesn't run any kind of function every 100ms. How does Gmail manage to implement this back/forward behaviour?

Answer 1

You might want to check this previous question :

http://stackoverflow.com/questions/136937/is-there-a-way-to-catch-the-back-button-event-in-javascript

It seems like the way it's done in jQuery is the only way to do it because that's what YUI is doing too :

http://developer.yahoo.com/yui/history/

Answer 2

Hey mate.

Perhaps you are talking about the jQuery History plugin here: http://www.balupton.com/projects/jquery-history Which has been used in many production quality sites; one of my favourites is http://wbhomes.com.au/

If so, it uses a 200ms test for older generation browsers which do not implement the onhashchange event natively. Without that event implemented natively, you have to workaround it's functionality by using a interval change - there just isn't any other way to my knowledge. Fortunately the latest versions of all the major browsers now support the onhashchange event natively, so this check is no longer needed.

But alas, let's go into what what that 200ms interval check does. If they are on IE6 or 7, it will check the state of an iframe (as in those browsers a iframe is required to emulate the back and forward buttons - where for other browsers a iframe is not required). If they are using another older browser which is not IE then it can just use location.getHash() in the check (without an iframe as explained before). Both types of checks are designed to be extremely fast and as minimal as possible, bringing the necessary overhead down to next to nothing. It's all about what the browser is actually willing to let you do, and trying to do it using the least intensive code possible.

Note: Before the v1.4.2-final (August 12, 2010) release of jQuery History the only recognised browsers which supported onhashchange natively was IE8 and above. This has been resolved in all newer versions of the jQuery History project.