Anyone have ideas for solving the "n items remaining" problem on Internet Explorer?

Question

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.

Answer 1

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.

Answer 2

With regards to caching images, I had to use an HTTP handler to get the images to cache correctly. Specifically, there was a picture of an arrow in a CSS menu that would cause the exact behavior you're dealing with since it was used multiple times in each menu.

Here is the code for the handler: http://www.groovybits.com/SrcViewer.aspx?inspect=~/PersistantImage.ashx

You use it by adding an AppSetting in web.config:

<add key="UniqueImageName" value="~/Images/image_name.gif"/>

And reference the source of each image using the handler instead of the path to the image itself:

~/Handlers/PersistantImage.ashx?key=UniqueImageName

Answer 3

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>';

Answer 4

It is to do with the "fix" for transparent PNGs in IE.

I was having this same problem with a site im working on and soon found there is no valid solution that fixes both this issue and the Transparent PNG images.

Answer 5

I have used this in the past with great success. You can also check this blog post.

Answer 6

This guy has a great writeup on IE6 caching problems, but the blog appears to be down.

He boiled the problem into two parts:

1. IE6 background-image flicker
2. An IE bug/feature: Internet Explorer Cache Is Not Used When You Run innerHTML Code to Insert the Same Image Multiple Times. Microsoft suggests two very bad workarounds (and in my case, they didn't even work), but you can also workaround this by making sure you don't insert <img> tags via innerHTML.

The natural solution to problem #2 is to use background-image instead of <img> tags; insidiously, this will force you right into problem #1; as a result, you may defeat problem #2, incorrectly believing you are making no progress.

In my case, I solved both problems at once, when I replaced my innerHTML <img> tags with <div> tags that had background-image and used document.execCommand("BackgroundImageCache", false, true) to fix the flicker.

Answer 7

this post has gone a long time and it seems that there's still no definite solution. sigh... nevertheless, this is helpful for others to have reference with the same issue and how others have tried to solve it.