当加载过长的下拉列表时，Internet Explorer 后退按钮损坏
我正在处理一些 ASP.NET 2.0 页面，当时我注意到某些页面的后退按钮不可用 - 呈灰色。 单击它们旁边的下拉菜单会显示清晰的结果，就好像我刚刚来到这个页面一样。 我查看了代码，试图找到一些东西来专门禁用后退按钮（重定向，聪明的 JavaScript），但什么也没找到。 所以我开始拆开页面，发现当两个特别大的下拉列表（其中一个有 38000 个项目！）被注释掉时，后退按钮将再次可用。 我所说的“注释掉”是指我没有在后面的代码中对它们进行数据绑定。
看来在我继承这个项目之前这些页面曾经可以工作。 我们所做的事情之一是将服务器从 .NET 2.0 升级到 .NET 3.5，尽管代码仍然针对 2.0 框架。 但我怀疑这就是罪魁祸首。
此问题在 IE 6 和 IE 8 以及所有最新更新中都会出现。 它发生在带有我能找到的所有更新的 Server 2003 RC2 上，以及客户端已选择性更新但都运行 IE 6 的 Windows XP 计算机上。
我的问题是，有没有人听说过这种情况，如果听说过，是什么原因导致的？ 这只是一个 Internet Explorer 错误吗？
I was working on some ASP.NET 2.0 pages when I noticed that some of the pages' back buttons were unavailable - greyed out. And clicking the drop down menu next to them showed clear results, as if I had come to this page fresh. I looked through the code trying to find something to specifically disable the back buttons (redirects, clever javascript), but found nothing. So I started picking apart the page and noticed that when two particularly large drop down lists (One had 38 thousand items!) were commented out that the back button would again be available. By 'Commented out' I mean I did not databind them in the code behind.
It seems that these pages used to work before I inherited this project. One of the things we did was upgrade the server from .NET 2.0 to .NET 3.5, although the code still targets the 2.0 framework. I doubt this is the culprit though.
This problem occurs in both IE 6 and IE 8 with all the latest updates. It occurs on Server 2003 RC2 with all the updates I could find and on Windows XP machines that the client has selectively updated but are all running IE 6.
My question is, has anyone ever heard of this, and if so, what causes it? Is it just an Internet Explorer bug?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，38k 个选项@ 28 个字符^1 单独为选项提供了 1,064,000 个字符的页面大小，更不用说附带的视图状态了。 当我想到这可能是杀死 IE 的原因，因为你的 POST 大小必须在兆字节范围内。
就我个人而言，我不会去解决您可能无法解决的问题，而是会从重构界面的更容易的方面来解决它，以便用户获得可管理数量的选项。 无论如何，我真的不知道如何才能在 38k 中选择正确的。 。 。
^1: <选项值=“x”>y 与 ASP.NET 生成的选项一样短，即 28 个字符。 我敢打赌我们正在查看的数据远不止于此。 我祈祷这是一个内联网应用程序。 。 。
Well, 38k options @ 28 characters^1 gives one a page size of 1,064,000 characters for the options alone, nevermind the accompanying viewstate. Which, when I think about it is probably what is killing IE as your POST size has to be in the megabytes range.
Personally, rather than beat on the issue which you probably can't fix, I'd go for hitting it from the easier side of re-factoring the interface so users get a managable number of options. I really don't know how one could pick the correct one in 38k in the first place anyhow . . .
^1: <option value="x">y</option> is about as short an option as ASP.NET will generate and that is 28 characters. I'd bet we are looking at far more data than that. I pray this is an intranet app . . .