Wednesday, September 26, 2007

IE6 is Crap By Design

I give up. I have had it. Internet Explorer 6 absolutely sucks.

Since I first started toying with JavaScript and using .innerHTML to dynamically add, change, or remove images on a web page in response to a user's actions or at page load (e.g. search icons tagged at the end of scientific references to coordinate user click-to-check existence of DOI, Handle, or PDF via Rod Page's JSON reference parsing web service at bioGUID.info), I have struggled with the way this version of the browser refuses to cache images.

If multiple, identical images are inserted via .innerHTML, IE6 makes a call to the server for every single copy of the image. Earlier and later versions of IE do not have this problem; these versions happily use the cache as it's meant to be used and do not call the server for yet another copy of an identical image. I tried everything I can think of from preloading the image(s), using the DOM (i.e. .appendChild()), server-side tricks, etc. but nothing works. Page loads are slow for these users and the appended images via .innerHTML may or may not appear, especially if there are a lot of successive .innerHTML calls. Missing images may or may not appear with a page refresh and images that were once present may suddenly disappear with a successive page refresh. Because AJAX is becoming more and more popular & as a consequence, there are more instances of .innerHTML = "<img src="..."> in loops, don't these people think something is not right with their browser? I doubt it. Instead, I suspect they instead think something is wrong with the web page and likely won't revisit.

Here's some example code that causes the problem for an IE6 user:

...
for (i=0;i<foo;i++) {
bar.innerHTML = "<img src="...">;
}
...


Web server log lines like the following (abridged to protect the visitor to The Nearctic Spider Database) fill 10-20% of these daily files:

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)

GET /bioGUID/magnifier.png - 80 - HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;...etc...)


So, I wonder how much bandwidth on the Internet superhighway is consumed by this terrible design flaw? Microsoft is aware of the issue, but weakly tried to convince us that this behaviour is "by design" as can be read in their Knowledge Base Article Q319546. Give me a break. The solution in that article is pathetic and doesn't work.

Depending on what you do in your JavaScript, you can either force an HTTP status code of 200 OK (i.e. image is re-downloaded, thus consuming unnecessary bandwidth) or an HTTP status code of 304 Not Modified ("you already got it dummy, I'm not sending it again" - but still some bandwidth). Though I haven't yet investigated before/after in my web logs, others have reported that the following code at the start of some JavaScript will force a 304:

try {
document.execCommand("BackgroundImageCache", false, true);
} catch(err) {}


I'm not convinced that this will work.

After pulling my hair out for 2+ years trying to come up with a work-around, I have concluded that the only way this problem can be prevented is if the user adjusts how their own cache works. If you are an IE6 user, see the note by Ivan Kurmanov on how to do this - incidentally, Ivan's server-side tricks also don't work). In a nutshell, if you use IE6, DO NOT choose "Every visit to the page" option in your browser's cache settings. Unfortunately, there is no way for a developer to detect a user's cache settings. Like pre-IE6 and post-IE6 users, people with IE6 whose cache is set to check for newer content "Automatically", "Never" or "Every time you start Internet Explorer" also do not have this problem.

Developers (like Mishoo) have suggested that this "by design" flaw is a means for Microsoft to artificially inflate its popularity in web server log analyses. But, I doubt analysis software confuses multiple downloads from the same IP address with browser popularity. So how can this possibly be by design if there is no way for a developer to circumvent it? Who knows.

The only real solution I have been able to dream up, though I haven't implemented it, is to perform a JavaScript browser version check. If people choose to use IE6 and don't upgrade to IE7 then they won't get the added goodies. I certainly don't want to degrade their anticipated experience, but I also have to think about cutting back on pushing useless bandwidth, which is not free. If you insist on using IE, please upgrade to IE7. This version of the browser was released a year ago. Better yet, make the switch to FireFox.

5 comments:

David Shorthouse said...

I have just now created an alternate version of the json parser to enable live search of references obtained from Rod Page's bioGUID.info service. This new version checks the version of the browser & if a visitor is using IE6, the search icons on e.g. http://canadianarachnology.dyndns.org/data/canada_spiders/AllReferences.asp are not shown. If you would like to receive this, let me know. Otherwise, you can look at the source of that page & grab the JavaScript there.

Edward Richards said...

While I definitely agree with you that upgrading to Internet Explorer 7 is more than just a user caprice, many companies still haven't upgraded to Internet Explorer. They just have a fear that some user computers can go tits up if they just rush in and upgrade all machines in the domain. I had similar experience when I've been upgrading mmm… that probably was an upgrade from IE 5 (or was it IE 5.5?) to IE 6. The versioning doesn't matter after all. What does matter is that we an avalanche of user calls to helpdesk when some users who came at work on Monday found their applications not working just because some components dependent on the IE were unable to start up. The interesting fact was that some users haven't experienced any problems. I learned then that everything should be tested before you get it deployed in a production environment. But how to do that? I stared with virtualization but some things still were requiring real deployments on physical machines. Someone told me to look to Scriptlogic's Desktop Authority which had a specialized component to work with updates and software deployments. I was skeptic about desktop management software because I had no clue why I need a desktop management why I just need to update my computers. However, when I tried Scriptlogic's product all my reservations disappeared. Now I am using it to deploy everything in my environment. It can also be used with a tool called MSI Studio that allows me to test setup packages in a sandbox. When I need to deploy software to some user or computer, I just simulate that user environment using Desktop Authority to see if this update or setup may cause errors by interfering with exiting software. And that's even without setting up the package! It checks the conditions and shows the results using probe technologies.

David Shorthouse said...

Edward: I do appreciate the issue in the broadest sense. As you point out, there are plenty of unintended consequences when one doesn't fully (or at least to the limit of one's patience) test a new deployment.

But, you wrote "The versioning doesn't matter after all." In this particular case, IE6 & only IE6 (other versions are fine) refuses to use its own cache when JavaScript builds image elements on a page in an innerHTML loop.

Edward Richards said...

No-no, David. I meant that in that talking about my particular case the exact version number doesn't matter. It doesn't matter for us to consider the case we faced with while upgraded the Internet Explorer. It doesn't matter if it was IE 5 or IE 5.5 that we upgraded to IE 6. But what does really matter is indeed what you are talking about. It mattered that we upgraded it to IE6 and it screwed up the user environment for some users. That's the fact that a change in version can crash all your procedures involved into working with the program and IE in particular. That's why I decided for myself that I make it a rule for our IT department that we test every application using the Scriptlogic's tool before deploying it into out production environment. Agree with you absolutely! Only that I'd suggest testing Firefox too and not hurriedly switching your browser to it if your business processes lie upon Internet Explorer. For example, me personally I find Internet Explorer 7 to be the best browser to work in multilingual teams and companies. And last but not least, the support of working with complex sites implementing much of Web 2.0/Ajax. Looks like Firefox may sometimes cause glitches in displaying the page especially when the site was specifically made for the IE model. I heard there are some problems with that how both browsers interpret CSS 2.
So usually we go along that way that implies testing the setup packages before the deployment. And the deployment itself should be flexible enough to reflect the particular needs for the particular user. And that's the kind of situations that I can easily handle with the tools in Desktop Authority. I think that the PCs within a corporate environment should be more personalized than a personal home computer. That's because each user needs their own set of software to perform the kind of work they've been hired to do. Engineering department needs its set of software whereas accounting needs another kind of software on their computers. One of the good example I'd like to give here are the designers which sometimes need to have a bunch of design programs and browsers to be installed on their computers. I know that it's usually very complex for the IT department to control that much software. So the complexity of the corporate environment is that you must keep the user desktop personalized but also keep the desktop standardized to meet internal corporate rules and standards. That's the kind of work that in my own opinion requires using some kind of desktop management tool. And particularly I find Scriptlogic's tool be more flexible than ones I've seen before. It allows me to combine the techniques I use to configure policies using the GPO objects while also allowing me to thoroughly configure user desktops based on the information I set.

Noel O'Boyle said...

You could include the image as a string in your javascript. Or download the string from a webserver (which hopefully would cache it). See example use in Line 123 of http://userscripts.org/scripts/review/11439