Your browser may have trouble rendering this page. See supported browsers for more information.

This page shows the source for this entry, with WebCore formatting language tags and attributes highlighted.

Title

Debugging IE 6: Operation Aborted

Description

<n>This article was originally published on the <a href="http://blogs.encodo.ch/news/view_article.php?id=6"><b>Encodo Blogs</b></a>. Browse on over to see more!</n> <hr> Develop your web application using Firefox. Validate your (X)HTML, validate your CSS, test your JavaScript. Tweak graphics, tweak layout. Get the client to sign off. Now that everything's looking and working just right, it's time to get it running in IE. Fire up IE and load the application. <div class="error">Internet Explorer cannot open the Internet site ''http://your.hostname.com/''. Operation aborted</div> ?!?! Lingering problems with PNG graphics, improperly interpreted CSS, imaginative approach to HTML layout---these are the types of problems you expect in IE. But IE refusing to load any page in the application at all? That's a new one. <h>What happened?</h> The first step was to load the <i>TamperData</i> extension with Firefox to get a look at the HTTP request and response headers. From this, it appeared that the server was using an HTTP 1.1-only feature by setting the <c>Transfer-Encoding</c> to <c>chunked</c>. Forcing Firefox to use HTTP 1.0 disables this feature and returns a <c>Content-Length</c> instead. Go back to IE and force the HTTP compliance to version 1.0 and reload the page. Nothing. Same error. So it doesn't seem to be anything on the server ... could it possibly be the content? This article, <a href="http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerProgrammingBugs">Internet Explorer Programming Bugs</a>, yielded a wealth of information, including the following lead: <bq>Apparently interacting with innerHTML and possibly using other JScript functionality causes IE to pop up "Internet Explorer cannot open the Internet site http://example.com. Operation aborted." messages after loading a page. ... It seems that IE doesn't like when somebody is trying to modify content of "document.body" by adding new elements (previous example) or by modifying its innerHTML (my case).</bq> Go back to the application and remove all scripts from the page, including the <a href="http://dojotoolkit.org/">dojo</a> libraries included by <a href="http://tacos.sourceforge.net/">Tacos</a>, an Ajax/scripting framework for <a href="http://tapestry.apache.org/">Tapestry</a>. Reload the page in IE and it loads without problems. Getting closer. <h>The Fix</h> Well, we can't just shut off Javascripting for a modern web application, so let's check for dojo/IE6 conflicts. Digging further turns up this post, <a href="http://dojotoolkit.org/pipermail/dojo-checkins/2006-March/004772.html">[Dojo-checkins] [dojo] #557: IE 6 refuses to load page if dojo is loaded in HEAD and a BASE tag exists before that.</a> The title says it all. Re-enabling the scripts and loading in Firefox confirms that there is indeed a base tag before the dojo scripts. Ok. So that seems to be the problem. We use the <a href="http://tapestry.apache.org/tapestry4.1/components/general/shell.html">@Shell</a> Tapestry component to render the HTML head, which has a <c>renderBaseTag</c> property. Set this property to <c>false</c> and the page works in IE as designed<fn>. <h>Addendum</h> We're using Tapestry 4.0.1 and had already extended the <c>@Shell</c> component to accept an array of scripts (analogous to the array of stylesheets it already accepts). Therefore, we simply changed the implementation to output the base tag at the end of the <c><head></c> section, to avoid any future conflicts in IE6. After a cursory examination of the sources for Tapestry 4.1, it seems that both the <c>delegate</c> and <c>ajaxDelegate</c> are rendered before the base tag, if present. This means that Tapestry 4.1 applications that require a base tag will also not function in IE6. We'll have to submit a patch in order to get this fixed once and for all. <hr> <ft>Well, kind of; now we have to fix PNGs and CSS and HTML and ... but we at least expected that kind of work. Outright refusal to load was something new and special, even for IE.</ft> <n>Using Firefox 1.5, TamperData 9.8.1, IE 6 SP2, Dojo 0.4, Java 1.5, Tapestry 4.02 and Tacos 4.0.1</n>