任何人有解决的＆QUOT思路; n项剩余的＆QUOT;在Internet Explorer上的问题？ [英] Anyone have ideas for solving the "n items remaining" problem on Internet Explorer?

问题描述

在我的ASP.Net应用程序，这是JavaScript的和jQuery沉重，而且还采用了母版页和.Net阿贾克斯件，我不断看到IE 6（偶尔IE 7）消息2项的状态栏上剩余或15个项目剩下的，其次是装载的 somegraphicsfile.png | GIF 的。此消息永远不会消失，可能会或可能不会从运行（它肯定似乎陷入瘫痪，但我还不能肯定）prevent一些网页的功能。

我可导致此通过只是清爽一个.aspx年龄发生的99％的时间，但项目的数量，有时它提到的文件而改变。通常它是2，3，12，13，或15

我GOOGLE了答案有几个建议或解释。他们中有些人还没有为我们工作，和其他人是不实际的对我们实施或尝试。

下面是一些想法/理论：

• IE不缓存图像对，所以它一再要求相同的图像如果重复页面上的图像和服务器假定，因为它已经在该页面的上下文送达，应当在本地缓存。 IE正确显示图像，但坐着等待那个永远不会到来的服务器响应。通常，它说，它正在等待重复页面上的文件。




• 该页面使用PNG图形透明度。确实是这样，但他们的jQuery-UI的ThemeRoller生成的图形，而根据对jQuery的UI人，是IE安全。 jQuery的UI组件都是使用PNG格式的唯一的东西。我们所有的PNG引用都在CSS，有没有什么帮助。我已经改变了某些图形从PNG到GIF的，但它同样可能说这是等待的 somegraphicsfile.png 的，因为它是对的 somegraphicsfile.gif 的




• 图像会在CSS和/或JavaScript指定，但在当前没有显示的东西（显示：无项目为例）。这的可以的是真实的，但如果是的话，我会觉得preloading图像会的工作，但到目前为止，增加了preloader没有什么好处。




• IIS的缓存策略是混淆浏览器。如果这是真的，它是具有与微软的浏览器问题（这并不让我感到吃惊的话）只有微软的服务器软件。不幸的是，我没有在将要承载的应用程序IIS配置的控制权。

有没有人看到了这一点，并找到打击的方法吗？特别是在ASP.Net与jQuery和jQuery的用户界面的应用程序？

更新

另外一个数据点：在页面中的至少一个，只是注释掉了jQuery的UI日期选择器组件安装程序导致问题走开，但我不认为（或至少我不知道），如果能解决所有的页面。如果它修理他们，我将不得不换出插件，因为该功能需要存在。似乎没有要反对的jQuery的UI任何悬而未决的问题IE6 / 7目前...

更新2

我检查IIS设置和启用内容过期是的不的设置我的任何文件夹。取消选中该设置是一项共同建议，为解决这个问题。

我还有一个更简单，页面，我可以持续创造上的错误。我使用了jQuery的用户界面1.6rc6文件（尽管我也试过的jQuery的UI 1.7.1具有相同的结果）。只有当我刷新包含了jQuery的UI日期选择器的页面出现问题。如果我注释掉的日期选择器的设置，问题消失。这里有几件事情我这样做的时候，我注意到：

1. 本页面总是说（1项剩余）下载图片的http：///images/Calendar_scheduleHS.gif，但重装只有当


2. 当我看着HTTP日志，我看到它请求图像从每一个是动态开启时间服务器，而不考虑缓存。


3. 所有该图形的请求是否完整且正确返回图形。无标记code 200或304（指示服务器告诉IE使用缓存的版本）。为什么它说等待时，所有的请求都完成了，我不知道该图形。


4. 还有就是页面（在UI PNG文件之一）上，有一个code 304单等图形（未修改）。在另一个网页，我设法登录HTTP流量与2项剩下的，两种不同的图形文件（包括UI的PNG）有304以及（但也不被列为下载的一员。


5. 此错误不是无害 - 页面并不完全响应。例如，如果我点击它应该执行一个客户端操作，页面刷新的按钮中的一个。


6. 从该页面将离去，回来不会产生错误。


7. 我已经转移到内容底部的脚本，脚本引用，这并不影响这个问题。该脚本仍然在$（文件）。就绪（）运行，虽然（它太毛茸茸的划分，除非我绝对必须的）。

最后更新和答案

有很多很好的答案及以下的建议，但没有人确切地是我们的问题。最近的一个（这也是导致我的解决方案）是一个约长运行JavaScript，所以我获得了奖金那里（我想我可以回答它自己，但我宁愿奖励通向解决方案的信息）

下面是我们的解决方案：我们必须在脚本中的$（文件）。就绪事件创建从ASP.Net母版页包含多个jQueryUI的datepickers。在这个客户端页面，一个本地脚本的$（文件）。就绪事件有脚本，摧毁了在一定条件下datepickers。我们不得不因为日期选择器的previous版本有一个问题，禁止使用消灭。当我们升级到jQuery用户界面（1.7.1）的最新版本，并用禁止S换成了消灭S为datepickers，问题就走了（或者大部分去了 - 如果你做的事情太快而页面正在加载，它仍然是有可能得到的状态）剩余n个项。

我为所发生的一切理论是这样的：

1. 页面内容加载，并有12个或
   所以文本框的日期选择器
   类。


2. 主网页脚本创建
   在这些文本框datepickers。


3. IE排队对每个请求
   日历图形独立
   因为IE不知道如何
   正确缓存动态影像
   请求。


4. 之前请求得到处理，
   客户区脚本破坏
   这些datepickers所以显卡
   不再需要。


5. IE是留下一定数量的
   孤立请求，它不
   知道该怎么做。

解决方案

我已经收到了类似的问题，它长时间运行的JS一块是在页面的中间是因为，浏览器正在等待它执行完之前，将完成下载其他文件的网站。

我不知道这是否是对你还是不是一个问题，但它以类似的方式表现出来。

In my ASP.Net app, which is javascript and jQuery heavy, but also uses master pages and .Net Ajax pieces, I am consistently seeing on the status bar of IE 6 (and occasionally IE 7) the message "2 items remaining" or "15 items remaining" followed by "loading somegraphicsfile.png|gif ." This message never goes away and may or may not prevent some page functionality from running (it certainly seems to bog down, but I'm not positive).

I can cause this to happen 99% of the time by just refreshing an .aspx age, but the number of items and, sometimes, the file it mentions varies. Usually it is 2, 3, 12, 13, or 15.

I've Googled for answers and there are several suggestions or explanations. Some of them haven't worked for us, and others aren't practical for us to implement or try.

Here are some of the ideas/theories:

• IE isn't caching images right, so it repeatedly asks for the same image if the image is repeated on the page and the server assumes that it should be cached locally since it's already served it in that page context. IE displays the images correctly, but sits and waits for a server response that never comes. Typically the file it says it is waiting on is repeated on the page.

• The page is using PNG graphics with transparency. Indeed it is, but they are jQuery-UI Themeroller generated graphics which, according to the jQuery-UI folks, are IE safe. The jQuery-UI components are the only things using PNGs. All of our PNG references are in CSS, if that helps. I've changed some of the graphics from PNG to GIF, but it is just as likely to say it's waiting for somegraphicsfile.png as it is for somegraphicsfile.gif

• Images are being specified in CSS and/or JavaScript but are on things that aren't currently being displayed (display: none items for example). This may be true, but if it is, then I would think preloading images would work, but so far, adding a preloader doesn't do any good.

• IIS's caching policy is confusing the browser. If this is true, it is only Microsoft server SW having problems with Microsoft's browser (which doesn't surprise me at all). Unfortunately, I don't have much control over the IIS configuration that will be hosting the app.

Has anyone seen this and found a way to combat it? Particularly on ASP.Net apps with jQuery and jQuery-UI?

UPDATE

One other data point: on at least one of the pages, just commenting out the jQuery-UI Datepicker component setup causes the problem to go away, but I don't think (or at least I'm not sure) if that fixes all of the pages. If it does "fix" them, I'll have to swap out plug-ins because that functionality needs to be there. There doesn't seem to be any open issues against jQuery-UI on IE6/7 currently...

UPDATE 2

I checked the IIS settings and "enable content expiration" was not set on any of my folders. Unchecking that setting was a common suggestion for fixing this problem.

I have another, simpler, page that I can consistently create the error on. I'm using the jQuery-UI 1.6rc6 file (although I've also tried jQuery-UI 1.7.1 with the same results). The problem only occurs when I refresh the page that contains the jQuery-UI Datepicker. If I comment out the Datepicker setup, the problem goes away. Here are a few things I notice when I do this:

1. This page always says "(1 item remaining) Downloading picture http:///images/Calendar_scheduleHS.gif", but only when reloading.
2. When I look at HTTP logging, I see that it requests that image from the server every time it is dynamically turned on, without regard to caching.
3. All of the requests for that graphic are complete and return the graphic correctly. None are marked code 200 or 304 (indicating that the server is telling IE to use the cached version). Why it says waiting on that graphic when all of the requests have completed I have no idea.
4. There is a single other graphic on the page (one of the UI PNG files) that has a code 304 (Not Modified). On another page where I managed to log HTTP traffic with "2 items remaining", two different graphic files (both UI PNGs) had a 304 as well (but neither was the one listed as "Downloading".
5. This error is not innocuous - the page is not fully responsive. For example, if I click on one of the buttons which should execute a client-side action, the page refreshes.
6. Going away from the page and coming back does not produce the error.
7. I have moved the script and script references to the bottom of the content and this doesn't affect this problem. The script is still running in the $(document).ready() though (it's too hairy to divide out unless I absolutely have to).

FINAL UPDATE AND ANSWER

There were a lot of good answers and suggestions below, but none of them were exactly our problem. The closest one (and the one that led me to the solution) was the one about long running JavaScript, so I awarded the bounty there (I guess I could have answered it myself, but I'd rather reward info that leads to solutions).

Here was our solution: We had multiple jQueryUI datepickers that were created on the $(document).ready event in script included from the ASP.Net master page. On this client page, a local script's $(document).ready event had script that destroyed the datepickers under certain conditions. We had to use "destroy" because the previous version of datepicker had a problem with "disable". When we upgraded to the latest version of jQuery UI (1.7.1) and replaced the "destroy"s with "disable"s for the datepickers, the problem went away (or mostly went away - if you do things too fast while the page is loading, it is still possible to get the "n items remaining" status).

My theory as to what was happening goes like this:

1. The page content loads and has 12 or so text boxes with the datepicker class.
2. The master page script creates datepickers on those text boxes.
3. IE queues up requests for each calendar graphic independently because IE doesn't know how to properly cache dynamic image requests.
4. Before the requests get processed, the client area script destroys those datepickers so the graphics are no longer needed.
5. IE is left with some number of orphaned requests that it doesn't know what to do with.

解决方案

I have had a similar issue before, and it was due to a long running JS piece that was in the middle of the page, the browser was waiting for it to finish executing before it would finish downloading the additional files for the site.

I'm not sure if this is an issue for you or not, but it had manifested itself in a similar manner.

这篇关于任何人有解决的＆QUOT思路; n项剩余的＆QUOT;在Internet Explorer上的问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！