Debugging IE 6: Operation Aborted
Published by marco on
This article was originally published on the Encodo Blogs. Browse on over to see more!
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.
Internet Explorer cannot open the Internet site ‘’http://your.hostname.com/’‘. Operation aborted
?!?!
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.
What happened?
The first step was to load the TamperData 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 Transfer-Encoding to chunked. Forcing Firefox to use HTTP 1.0 disables this feature and returns a Content-Length 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, Internet Explorer Programming Bugs, yielded a wealth of information, including the following lead:
“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).”
Go back to the application and remove all scripts from the page, including the dojo libraries included by Tacos, an Ajax/scripting framework for Tapestry. Reload the page in IE and it loads without problems.
Getting closer.
The Fix
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, [Dojo-checkins] [dojo] #557: IE 6 refuses to load page if dojo is loaded in HEAD and a BASE tag exists before that. 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 @Shell Tapestry component to render the HTML head, which has a renderBaseTag property. Set this property to false and the page works in IE as designed[1].
Addendum
We’re using Tapestry 4.0.1 and had already extended the @Shell 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 <head> section, to avoid any future conflicts in IE6.
After a cursory examination of the sources for Tapestry 4.1, it seems that both the delegate and ajaxDelegate 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.
[1] 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.↩
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