Browser's back button disables randomly in ASP.NET application

On my two-page web application, users progressively enter info and make selections on page one. When done, they click a 'Generate' button that navigates to page two. Users print that page and hit the browser's Back arrow to return to page one with selections intact.

After a few generated pages (2 or 3), clicking Back just disables the icon without going back. They have to manually revisit page one, reentering their info and selections.

I found that the down arrow to the right of to the Back / Forward arrows (IE8) that shows the immediate history generally includes all 'previous' pages. But when the back button is about to disable on click, the history only shows the current site.

What events, scripts, headers, etc. clear the history for the current site? It occurs in IE7 and IE8 on WinXP and Win7. In FireFox, the button did not disable, but it did not do anything either. Users report it as a recent and I have been making changes to the appl开发者_Go百科ication, but it only affects the HTML on page two (not scripts, though). It's probably a code issue if it's recent, but I'm not sure what to look for when double checking my recent changes.

---

Which version of IE?

Internally, IE maintains a limited amount of data in the travellog (aka back/forward stack). ASP.NET pages with huge postback forms often blow this limit, wiping the history stack.

In IE6 and IE7, if there is a form input field with a value longer than 523,659 characters, when you navigate away from the page, IE may clear the current session's travellog (similar to history), disabling the back and forward buttons.

I believe the overall Travellog size limit was upped somewhat in IE8, but it's not more than a few megabytes.

---

As a general rule, if you want your users to navigate back and forth between pages, I would give them links on the page that do the job (without using javascript:back()) instead of using the browser's navigation.

What's happening, most likely, is that the postbacks of a single page are sometimes considered pages, sometimes not. If a user action loads a page that has the same URI and query string, most browsers consider that "the same page" even though EVERYTHING may have changed. This is usually due to heavy use of MultiViews with the information about the current view kept in ViewState or Session; navigating within that page doesn't change the URI being navigated to, so the browser doesn't log each new load as unique.

If you really need proper back-and-forth functionality, you will need to make sure that every link will result in the browser being told to navigate to a different URI than the current page. You can do this by adding a query string element that will be present in every link to a different page or view, that will auto-increment with each click the user takes. This gives the browser a different URI every time. You only use the existing QueryString element to create the new one on your links' URIs. This can get cumbersome, and the easier solution is simply to provide in-page navigation and tell your users not to hit "Back" any more.