It works that way on stackoverflow, reddit and many other popular websites. (try to add test comment to this question, then navigate to different page and hit back button to come back – your comment will be “gone”)
This makes sense, yet some websites (apple.com, basecamphq.com etc) are somehow forcing browser to serve user the latest state of the page. (go to http://www.apple.com/ca/search/?q=ipod, click on say Downloads link at the top and then click back button – all DOM updates will be preserved)
where is the inconsistency coming from?
One answer: Among other things, unload events cause the back/forward cache to be invalidated.
Note that the behavior of the bfcache is different from the standard browser cache with regards to Cache-Control and other HTTP headers. In many cases, browsers will cache a page in the bfcache even if it would not otherwise store it in the standard cache.
jQuery automatically attaches an unload event to the window, so unfortunately using jQuery will disqualify your page from being stored in the bfcache for DOM preservation and quick back/forward. [Update: this has been fixed in jQuery 1.4 so that it only applies to IE]
- Information about the Firefox bfcache
- Information about the Safari Page Cache and possible future changes to how unload events work
- Opera uses fast history navigation
- Chrome doesn’t have a page cache (, )
- Pages for playing with DOM manipulations and the bfcache:
I’ve been trying to get Chrome to behave like Safari does, and the only way I’ve found that works is to set
Cache-control: no-store in the headers. This forces the browser to re-fetch the page from the server when the user presses the back button. Not ideal, but better than being shown an out-of-date page.
This has nothing to do with the hash (#) symbol.
If you would check apple’s HTTP headers, it’s simply caching the page.
Using the URL hash/fragment identifier is a pretty common way to hook/remember state in a web application that relies on Ajax and DOM updates.
Check out the Really Simple History project for some ideas. It’s possible to monitor the URL for changes to the hash, and rsh does this, taking into account browser differences.
For anybody running in problems with
Rails and this — your issue isn’t bfcache (I thought it was) — it’s the
turbolinks gem. Here is how to remove it.
Hopefully this’ll save you some time and banging your head against the wall.
What you are looking for is for some type of URL hash management. The # in the url is for client side only.
When you change the state of the back with JS, then you update the data in the # of the url.
Also you add some type of polling that monitors if the hash has changed, and loads the state of the page based off the new data in the hash.
Take a look at this: