The return button in the browser is disabled randomly in an ASP.NET application.

Question

In my two-page web application, users gradually enter information and make choices on the first page. When this is done, they will click the "Create" button, which will go to the second page. Users print this page and click on the Back arrow to return to the first page with the options intact.

After several generated pages (2 or 3), pressing Back simply turns off the icon without returning. They must manually revise page one by re-entering information and choices.

I found that the down arrow to the right of the Back / Forward arrows (IE8), which shows an immediate history, usually includes all the “previous” pages. But when the back button is about to turn off when clicked, only the current site is displayed in the history.

What events, scripts, headlines, etc. clear the history of the current site? This happens in IE7 and IE8 on WinXP and Win7. In FireFox, the button did not turn off, but did nothing. Users report this as recent, and I made changes to the application, but it only affects the HTML on the second page (and not the scripts). This is probably a problem with the code if it was the last, but I'm not sure what to look for when you check for my recent changes.

Answer 1

What version of IE?

Internally, IE supports a limited amount of data in the travellog (aka back / forward stack). ASP.NET pages with huge postback formats often cause this limitation, erasing the history stack.

In IE6 and IE7, if there is a form input field with a value exceeding 523,659 characters, when removed from the page IE can clear the current travellog session (similar to history) by disabling the back and forward buttons.

I believe that the overall Travellog size limit has grown slightly in IE8, but not more than a few megabytes.

Answer 2

Typically, if you want your users to go back and forth between pages, I would give them links on the page that are doing the job (without using javascript:back() ) instead of using browser navigation.

What happens most likely is that the postback of one page is sometimes considered pages, sometimes not. If a user action loads a page with the same URI and query string, most browsers consider the "same page" even if everything can be changed. This is usually due to heavy use of MultiViews with information about the current view stored in ViewState or Session; Navigation on this page does not change the navigation URI, so the browser does not register every new load as unique.

If you really need the correct back-and-forth functionality, you need to make sure that each link will cause the browser to be prompted to go to a different URI than the current page. You can do this by adding a query line item that will appear in every link to another page or view that will automatically increase each time the user clicks. This gives the browser a different URI each time. You only use the existing QueryString element to create a new URI for your links. This can be cumbersome, and a simpler solution is to simply navigate the pages and ask your users not to hit Back.