We have an ASP.Net (Web Forms) site hosted on IIS7.

The site contains a table with information retrieved from a database. Paging is enabled for this table, meaning that only 10 rows are displayed at a time. (This is done with server-side code; as far as the browser is concerned, the table contains no more than 10 rows.)

Once the DB reached over 1000 rows, the browser began disabling the back-button after the page loaded. Sometimes the back-button remained enabled until users navigated to another website, and only then became disabled (instantly).

After deleting some info in the DB, the problem stopped. But once the amount of records passed 1000, it started again.

This only happens with Internet Explorer (no matter what version). This does not happen with Firefox or other browsers.

Note: The back-button becomes disabled, but the history is all saved.

Why does this happen, and how can it be fixed?

The amount of records retrieved should only affect the server; the browser has no idea how many rows were retrieved. And yet, the "choice" to disable the back-button is client-side!

Here's a link to the question on StackOverflow.

  • This question would be better asked at stack overflow. – toomanyairmiles May 20 '12 at 13:35
  • @toomanyairmiles, I thought so at first, but it's the browser that disables the button, and there is nothing in the code that deals with the browser! – Yehuda Shapira May 20 '12 at 13:40
  • It doesn't really make sense that IE would disable the back button, more likely that the fault is in the data that is being fed to it - are there any differences in the urls between 999 lines and 1001 lines. – toomanyairmiles May 20 '12 at 14:43

It's a known problem on large pages in Internet Explorer, something to do with viewstate bloat. Preventing viewstate bloat https://stackoverflow.com/a/951796/722112

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.