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:
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:
The company is encouraging users to shift to Microsoft Edge instead, which has legacy support for Internet Explorer-based websites built in. While the effective end of life for Internet Explorer had happened last year, it still allowed users to use Explorer with limited functions.
IF you use behaviors ANYWHERE in your code (or a library you use uses them) e.g.
<style> body * { behavior:url(anyfile.htc); } </style>
Then there is NO solution that I'm aware of and the bug report filed in IE Feedback on Connect for IE8 (and IE7) was rejected for both releases with the following blanket canned statement:
This is a known bug in IE and also happens in previous IE versions. The reason that you see hundreds of requests in the status bar is because IE attemps to read the htc file from disk over and over again for each element on the page. Unfortunately, at this time we do not plan on fixing this. We will consider this in the future version of IE.
Best regards, The IE Team
Since this is the same reply received for IE7 development I wouldn't hold my breath on EVER having this fixed.
Update:
One additional thought based on your update notes. If the page isn't quite responsive, as if it is still loading something, check the rendered DOM content for any calls to document.write()
{you may not have added them, but a lib might have}.
If they exist, try adding a document.close();
statement after they are complete, this will tell the browser you are "done" rendering.
PS here is a link you can save as a bookmark (right-click "Add to favorites...") that will show you the generated DOM as IE sees it (an ugly quoteLess=CaMelCaSeMeSS) do a search on the result to find any quirky code that might be causing issues.
IE Generated Source: (add this as the location for any bookmark, the editor won't let me link it up)
javascript:'<xmp>'+window.document.body.parentNode.outerHTML+'</xmp>';
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With