How to mix AJAXy page updates with the Back button so that the updates are still there when the user returns?

Question

I have a page that the user can modify. All modifications are performed using JQuery, and also sent to the server, so that a full reload will produce the modified page too.

This works fine in Firefox 11 / Chrome on Windows: even if the user navigates somewhere else and then uses the "Back" button, they get the page with their latest edits.

However, if I now embed Google Maps onto the page, the Back button stops working: it takes the user to the page how it was before all their edits. This page doesn’t even exist anymore except in browser’s cache, and yet it gets displayed.

I’ve put together a simple testcase here that shows this behaviour.

What gives? How can I fix this? The perfect solution would just allow the browser to go Back without reloading the page, like it would do normally.

P.S. Apparently the "working" example doesn’t actually work in Chrome on OSX either. How can I work around the browser’s insistence on going back to a stale version of the page?

Bug reports describing this behaviour: Firefox

---

Bounty: Firefox and Chrome on Windows exhibit both behaviours (going back to the modified DOM in one case, but unmodified in another). Is there a spec describing what the browser should do? Are there bugs filed to change this one way or another? Does this issue have a common name that I can google?

I’m considering a solution whereby I update a hidden element via JavaScript, and then check if the update is still there. If so, the "Back" button restored up-to-date DOM, and nothing else needs to be done. If not, the browser restored outdated DOM, and I can just force a page reload, as unpleasant as that is. Any comments on this approach are also welcome.

Note: the real website has more editable controls than that, and one of them is a freeform text area. I would like the proposed solutions to work even if the user has just added several paragraphs of text. That kind of thing can’t be appended to the URL after the #, for example.

Answer 1

Embedding Google Maps into the page disables the bfcache (I'll use the Mozilla term for lack of a standard one) because the maps page loaded in an <iframe> uses an unload listener.

The possible reasons for a page not being cached for fast back navigation in Firefox are listed on MDN: Using Firefox 1.5 caching. Your problem is listed as "the top-level page contains frames that are not cacheable", which is confusing, I'll try to clarify it later. (Other browsers probably use similar heuristics, since these rules were developed to avoid breaking existing content - see also this answer, it has some links.)

The correct way to fix this would be to befriend someone at Google and then nag them until they remove the onunload listener at least from maps' embedded pages.

In general you shouldn't ever rely on bfcache working or not working for a particular page. It's just an optimization for the common case. Since it's an optimization, it could be disabled, for example when the system is low on memory. It also won't work if the user restarts the browser before going back, or closes the tab and picks 'undo close tab', as you noted in the bug.

You should either restore the page's state from JS or mark the page as not cacheable (using an HTTP header). The former results in a better user experience, of course. @Adam Gent's suggestion looks correct, I'll have to check what Firefox problem he refers to.

---

The reason bfcache works this way is:

• If the browser runs an onunload handler, then restores the page via bfcache, the page could be broken, since scripts often remove the event listeners in the onunload handler (to "clean up", which is not really necessary except in old IE versions)
• if the browsers stopped running onunload handlers in a page on the basis that the user might return to the page and they'd like to cache it, the authors would complain.
• if a page in an iframe can't be cached, restoring a cached outer page and reloading the inner page would break them sometimes (e.g. if both pages are same-domain, the outer page can hold references to objects in the frame, which won't be valid after the inner frame is reloaded). So if an iframe is not cached, neither is the parent page.

The reason the page is still loaded from the (disk) cache when you hit "back" is that presumably you specified that the content you sent to the browser can be cached. The browser has no way to know that you update the page on the server in parallel with making the DOM changes to it.

---

[edit]I'll elaborate on the "mark the page as not cacheable" idea above. To make web browser cache work for, and not against you, it's important to remember that HTTP is a protocol for retrieving resources. For example, the HTML page identified by the URL http://bbb.akshell.com/broken is a resource. When you serve a resource over HTTP you specify how long the browser's copy of the resource will be valid (i.e. matching the canonical version of the resource on the server).

When, as in your testcase, the resource is an HTML page with the item selected by the user marked up in a special way, the resource may change at any time (every time the user changes the selection). This means that the honest HTTP response when serving this resource would be "don't cache, may change at any time". The browser would then reload the page from the server every time it needs to load the page -- correct behavior, but at the cost of slowness for the user.

An alternative approach, appropriate for things like switching between multiple in-page tabs would be to associate each selection with its own URL. A page with two tabs would correspond to two resources (and two URLs) -- one for each tab. Both resources could be (HTTP-)cached by the browser. Changing the URL and the page's content could be implemented without the roundtrip to the server via pushState.

Another approach, which seems more applicable to your case, in which you save the user's input on the server: separate the app UI and the user's data into different resources (i.e. a static (HTTP-)cacheable HTML page with JS, loading the user data from a separate non-cacheable URL). Request the user data and update the UI on load.[/edit]

Answer 2

This trick will clear bfcache for FireFox:

window.onunload = function(){}

Answer 3

If you don't care about old browsers you could use a combination of local storage and pushstate.

Using @lucian.pantelimon 's solution + pushstate + localstorage should get you what you want.

<script>
window.addEventListener("popstate", function(e) {
    alert("hello"); // do my restoration from localstorage.
});
</script>

@TimWi is right that if the browser doesn't fire an event your kind of "up shit creek".

One thing you might want to investigate is a truly gross hack of a frameset (ala reddit/google images/linkedin article style).

EDIT: Looks like the pushstate events don't get fired off when the back button is pressed on a remote site back to your site.

EDIT 2: It looks like my firefox v 10.0 has problems with pushstate. It works fine in chrome.

Answer 4

Your 'working' page doesn't work for me either--at least not the way you want it to.

It looks like you update the page's DOM via jQuery, then send an update back to the server, but never force the browser to grab the latest from the server. So the back button behavior is entirely dependent on the browser deciding to either cache the last server request, or the last state the DOM was left in.

You could try updating the URI with a query string when you do the DOM update via jQuery. That may force the browser to grab the latest upon return.

Answer 5

Assuming you don't trust the browser, depending on the difficulty on the changes, you could use link name for indicating the page state.

For example, your "Select me!" link #3 would lead to http://bbb.akshell.com/broken#link3. That won't make the page reload. So even if the page is loaded from the scratch after "Back" is pressed, you still have the #link3 in url and you can use it to get the page into the state you want (in this case, fire "Select me!" #3).

You could also generate some more complicated urls to make up for more complicated changes. I believe mechanics like that of some sort are used to navigate onto the specific section of flash website when everything is handled by the same flash movie.

P.S. That is the "I don't trust the browser" solution. If you do trust - a solution needed that works in every one of them, I would be interested to see it as well.

Answer 6

You could try storing as much information as possible in the cookies and "rebuild" the page when needed.

Not quite a clean approach as the cookies will be sent every time you access the page (limiting the amount of data stored in the cookies is a must-do here I think), but it should be cross-browser compatible.

Another way would be to store the data in window.name. For pros, cons and a couple alternatives for this approach look at Using window.name as a local data cache in web browsers.

EDIT: It might be useful to store the states of the application and associate an id with each one, then add something like #stateID<state id here> to the address. When the user clicks the back button, you can know which state to load.

I.E.:

Say your state contains the selectMeItemSelected and mapInfo{latitude, longitude, zoomLevel} information.

When the user first enter the site you save stateID #1 in the cookies (or somewhere else, but I'll be using cookies in this example) as:

 state[1].selectMeItemSelected = 1;
 state[1].mapInfo.latitude = 45;
 state[1].mapInfo.longitude = 45;
 state[1].mapInfo.zoomLevel = 2;

After this you add #stateID1 to the website address.

When the user makes an action that activates your AJAX code, you store another state in the cookies, change the URL to #stateID2 then resume running your AJAX code.

When you detect that the user has clicked the back (or forward) button, just load the page using the info stored in the state.

If you generate the stateIDs sequentially, you should also clear the states that follow the current state before adding the new state. This way you get the behavior of the back and forward buttons in the browser: if you click back from stateX, then click another link (can be AJAX), you won't have an active forward button active to click to go "back" to stateX and you can consider clearing that state.

This approach does not work with bookmarks, unless you store the states on the server and pass the state information each time or implement some kind of permalink.

Answer 7

I don’t know whether all browsers will run the domready event (or indeed any event) when you press the Back button and it takes you to a cached page. It is clear that if a browser doesn’t run any events then, there is nothing you can do.

However, my suspicion is that they will run the domready event. If they didn’t, jQuery event hooks that are added via $(function() { ... }) wouldn’t be set, and if that were the case, I probably would have encountered the bug much more (because it would be a lot more visible to me as a user).

Therefore, my suggestion is to handle the windowunload† event; within that event, hook some code to the domready event that checks whether the page is in the modified state or the original, unmodified state; and if it is in the unmodified state, force a reload of the page. (You could, in theory, do this reload in an ajaxy fashion so that it doesn’t affect the browser history.)

You therefore need to mark the page as modified or unmodified. For example, you could add an attribute to the body element every time the page is modified. In jQuery I would recommend to use data:

$(document.body).data('modified', true);

Of course the downside is that you need to do this in every ajaxy piece of code that modifies the page. If you have a centralised function that all your ajaxy DOM modifying goes through, it’s quite a bit easier.

Here’s my attempt for the windowunload† handler:

$(window).unload†(function() {
    $(function() {
        if (!$(document.body).data('modified'))
            forceReload();
    });
});

Of course you’ll have to write forceReload() yourself. It could be a simple location.reload‡() or an ajaxy call.

† I don’t remember the exact name of the event or the jQuery function to hook to it.

‡ Likewise, check whether it was called reload or refresh or something else.