Pete Freitag Pete Freitag

AJAX on IE - back to the IFRAME


On Internet Explorer in order to write AJAX based web applications you have to use an ActiveX object.

var request = new ActiveXObject("Microsoft.XMLHTTP");

On browsers that support the XMLHttpRequest object (Safari, Firefox) you instantiate your asynchronous http object as follows:

var request = new XMLHttpRequest();

Most AJAX apps have a browser check to determine which one to use.

Kae Verens recently pointed out in a blog entry that web sites that use AJAX won't work on IE when ActiveX controls are disabled in the security settings.

This is an important point to ponder when considering AJAX for a web application. Lots of companies will have ActiveX controls disabled, and keep in mind that IE is still the most popular web browser.

So how do you fix this? Back to using hidden IFRAME tags, which I have always thought worked just fine. Kae, has actually written some javascript to do this in his article.

I have actually looked around for some discussion on IFRAMEs vs XMLHttpRequest (aka AJAX), but haven't found much. There are a few nice features of the XMLHttpRequest object, those mostly deal with access to headers, status codes, and other http details. Which is nice but you don't always need that info.

Are there any other advantages to using XMLHttpRequest objects over IFRAMEs?

Like this? Follow me ↯

AJAX on IE - back to the IFRAME was first published on August 17, 2005.

If you like reading about activex, ajax, ie, iframe, firefox, xmlhttprequest, or javascript then you might also like:


Probably the most obvious advantage of the XMLHTTPRequest object over IFrames is that there is a single universally accepted API with the ibject, whereas with IFrames, the developer has too much choice, making it too easy to write in a way that may be difficult to simply "plug in" to another project. That's why I chose to replicate the object even though I was using IFrames - I didn't want to rewrite so many cool libraries - with the standard XMLHTTPRequest API, it was virtually plug and play, for example, to hack Sajax to work with it.
by Kae Verens on 08/17/2005 at 5:36:00 PM UTC
A nice article on remote scripting with iframes can be found on the apple site: It's from way back (january 2002), but it's still valuable. One of the drawbacks of iframes would be the browser refresh/back buttons, as the article points out (and then also tries to solve).
by Halans on 08/18/2005 at 7:06:44 AM UTC
not sure about the benefits of using iframes over the xmlHttpRequest object, though i've played with both, and given the choice there really is no question in my mind.... xmlHttpRequest all the way. but that's just me. iframe's can be a pain in the ass, to code and to style properly in the page -- esp. getting it to look proper or the same across all the major browsers... least, that's what i've found ;)
by forgetfoo on 08/19/2005 at 9:46:20 AM UTC
forgetfoo - I think you are misunderstanding the point of the iframes method I came up with. It's not to /replace/ the XMLHTTPRequest methods, but rather, to transparently offer an alternative, when IE is set to not run ActiveX. I don't understand why IFrame style comes into it at all, either. If you'd read the source of what I wrote, you'd see that the IFrame is never actually displayed on the page. And - across all the major browsers?? This code is to solve a problem /specifically/ in IE - no cross-browser support needed!
by Kae Verens on 08/19/2005 at 10:09:30 AM UTC
couldn't a framework be developed that switches over to dynamic creation of iframes if XHR isn't available and simulates XHR through that, transparently for the designer?
by lala on 08/19/2005 at 10:21:24 AM UTC
lala - that is exactly what my article was about. Here it is, implemented using the Sajax framework:
by Kae Verens on 08/19/2005 at 10:39:23 AM UTC
I definitely think that using IFRAME's for the time being will solve a lot of cross-browser compatibility issues. There is an open source php/javascript library, using a hidden iframe to perform database/server requests without refreshing the page, at I've found it pretty simple to use.
by Jason Jones on 01/02/2006 at 10:14:50 PM UTC
People say Ajax breaks back buttons... try iFrames ;) But it's also the little things about xmlHttpRequest that give it an edge over iFrames. Like the "clean" way to create/distroy "loading" flags. With the readystatechange property of xmlHTTP you can create a flag on "state 1" and destroy it on "state 4".
by Todd on 03/25/2006 at 5:03:23 PM UTC
Ryan - yes, it does. For example, I wrote my original ActiveX workaround for the website (note the s).
by Kae Verens on 05/18/2006 at 11:14:50 PM UTC
I did iframes with WDDX/CF/Javascript over three years ago, before AJAX and the whole XMLHttpRequest, and it was for a killer webapp, also over https. it works like a charm ;-)
by Sebastiaan on 10/27/2006 at 6:36:00 PM UTC
I can only give you the starting page as it is a secured app for registered users only ( Please don't mind the certificate issue - we're trying to resolve this as quickly as possible. If you have specific questions I can try and answer those with code examples.
by Sebastiaan on 12/06/2006 at 4:19:42 PM UTC
Ajax over SSL works fine... except for on IE6. Randomly the requestor will quit immediately claiming an error status 12029, 12030, 12152, 12159 and a couple others. I'm racking my brains over a way to reliably code around this and would love suggestions from anyone that has had this experience and solved it. Perhaps it's fixed in Msxml2.XMLHTTP.6.0 - but it will be a while before everyone is there...
by perkiset on 04/10/2007 at 1:13:43 PM UTC
Steve and Perkiset, either of you figure out why AJAX XHRs may not work over SSL/HTTPS? For me, it works great in development, but I start getting that 12030 error for a very specific point. I'm using Dojo 0.4.1's FormBind, which posts a Web 1.0 form through an asynchronous request to an SSL URL. Given the fact that I'm already authenticated, and just trying to post/submit a form to a Struts Action...if the form's validate() fails, I get a 12030. Otherwise I can post the form just fine and get the response back all peachy. Anyone seen anything like this or have any suggestions? I'm about to give up and go back to refreshing the page by posting with a normal old boring 1.0 form submit...
by Blue Rose on 05/02/2007 at 7:09:07 PM UTC
I think a bunch of you are missing the point of the iframe... it's not for display. It's just a vehicle for getting back the server response.
by JJ May on 10/11/2007 at 12:51:50 PM UTC
Anonymous - how did this fix all of your errors? Do you have a place where you have demo code? The problem for me is on the send, not the response - are you saying that this is actually an unclosed PREVIOUS connection and that fixed it? I'll have to try that, but would love more details from you
by perkiset on 11/04/2007 at 9:39:06 PM UTC
I created web service using REST.It works fine mozilla 2.0. But in IE and mozilla 3.0 it doesn't work.the exception is security error.give the solution.
by ilango on 08/08/2008 at 12:39:22 AM UTC
I think either DOM injection or iframes will do the job. At least as far as the bandwidth and server horse power won?t let a ajax page refresh or evolve to let say show, for example, an animation where the info to be drawn homogeneously may be rendered/sent by the server really fast. We may play with that at this time on our local configs, but for drawing basic htm content remotely? I have to say that iframes are much easier/faster and cross-plateform to implement for the moment. Regarding the back-forward thing, something tells me that back-forwarding with anchor hashes, data cached in each iframes is really fast and enjoying on a navigation point of view.
by Kaveh Rassoulzadegan on 03/28/2009 at 9:26:04 AM UTC
hello , I have a one ajax file and one calling file to ajax I have some error on IE browser only one time. when first time load page on ie browser create error and second time remove them please suggest what is problem in ajax return file code
by Ensys software on 09/14/2009 at 6:54:46 AM UTC