AJAX on IE - back to the IFRAME

August 17, 2005

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?

Related Entries

13 people found this page useful, what do you think?


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.
Making 10 different XMLHttpRequests at time seems to be a little bit easier and clearer than to create 10 IFRAMES.
A nice article on remote scripting with iframes can be found on the apple site: http://developer.apple.com/internet/webcontent/iframe.html 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).
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 ;)
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!
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?
lala - that is exactly what my article was about. Here it is, implemented using the Sajax framework: http://verens.com/demos/Sajax.phps
We find that using an Iframe and WDDX packets works much better than ajax for us.
Using back-button will change the iframe, not the current page. Confusing to users...
My web application has two parts: - the customer interface use iframes (as IE5 on OSX won't initialize XMLHttp (no matter what I tried) and "our customer" are students within the U system (IE on OSX likely to be used). - the admin interface mostly use AJAX except the part where we have a list of schedule slots for consulting. This list is displayed in a table within an iframe (autoscroll), which has around 500-800 rows. Using ajax, I would have to wait for all the data to load before displaying, but with iframe, the first portion of the table appears right away, user can look at them while the rest is loading, and they don't scroll down very often. I have tried to display the table partially with AJAX (before state 4) but then it will crash the javascript to highlight and display info for each row. I think each technique has its own cons and pros, and they are just tool. We are not forced to choose one over another. Just like the 4-years CS program, they teach you all programming languages and paradigms so that your thinking won't be limited by the language.
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 http://simpletutorials.com/tutorials/jsrs/index.php I've found it pretty simple to use.
Show me an iframe in IE with 100% height that actually manages to size itself to the page displayed in the iframe. Fine in Mozilla - not easy to achieve in IE.
You're not meant to do that. You're meant to hide it, and do JS calls inside the frame. The JavaScript library I'm developing has an Ajax component which will try XMLHttpRequest and fall back to iframes *transparently* if it fails.
I have problem regarding automatic login. I am giving my target URL to If. And in Form's action login page's URL. But if am doing first time then its giving error.. And if i have already sign in then its taking me on my target URL.
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".
Dojo (dojoproject.net) has an api that pretty much makes these interchangeable and makes it easy to have iframes as a backup method. Disclaimer: Said project has good documentation for said functionality, the event system and the base functionality however if you want to use its (undeniably awesome) widgets library you might find yourself rummaging through source code and swearing lots before you can get something that works.
tried using XMLHttpRequest on a server using https... no luck because it only supports http. and XMLHttpRequest worked sooo good on my development system so promising but try to implement it on a live server that uses ssl and burn! so I am back to using iframes.
Well, folks don't use AJAX just for the XmlHttp async features, they use AJAX for building rich DHTML client application that doesn't require page loads. Sure you could use an Iframe for each section in your page, but those are very hard to style and manage from js.
Steve in my quick google searching I found references saying XMLHttpRequest *does* support SSL? It won't be very useful for me if it doesn't....
Ryan - yes, it does. For example, I wrote my original ActiveX workaround for the website https://inkjet.ie/ (note the s).
SSL works great I had an iframe that I was creating that was causing my ssl problem!
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 ;-)
Can you demo? http://phpbasic.com
I can only give you the starting page as it is a secured app for registered users only (https://aanmelden.cao.szw.nl). 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.
I think that AJAX is a bit of a lemon to be honest. The messing about behind the scenes to try to maintain a connected page is just too much messing about and not particular standards compliant. Just use JavaScript (ECMA Script) and use an object to display the dynamic part of your target page. On various actions you may well have to refresh you're page but if they're cleanly coded and not stuffed with bloated graphics and other useless crap, they should load up in no time anyway - using client-side javascript components for things like calendars and intelligent grids also improves performance very effectively whilst being completely cross browser. I NEVER use any alternative code or browser checks in my code and it all works identically in all browsers despite having some pretty fancy features in some cases. One codebase for all or nothing, that's my view. ECMA Script rules.
Can u please tell me that under which tag i write this code. Thanks!
Microsoft has published an article on how to use the XMLHTTPREQUEST in this day and age: http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx
Iframes has numerous advantages over AJAX. btw Badman.. I hope everyone thinks just like you... makes pioneering easier ;)
The annoying sound which is played on every iframe-reload is one point for me to prefer the XMLHttpRequest Object. I know that you can disable the sound in preferences but the "normal" user won't do that.
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...
private void RefreshFrame() { //Refresh the iframe. StringBuilder sb = new StringBuilder(); sb.Append("<script type=\"text/javascript\" language=\"javascript\">"); sb.Append("window.parent.document.frames['ifTabs'].location.href=window.parent.document.frames['ifTabs'].location.href;"); sb.Append("</script>"); Page.RegisterClientScriptBlock("Script", sb.ToString()); }
There are several rather active discussions going on about this at http://www.perkiset.org/forum/ . Check the Javascript and Ajax boards.
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...
Hey Blue Rose - Actually we have a pretty lively discussion going on about it over at my forum, http://www.perkiset.org/forum/ - nope - haven't figured out *why* yet, but at least we've discussed some workarounds that seem to be doing OK. Since ALL of my ajax requests are POSTs (t's just the choice I made) I see it regularly, although randomly. There's been a lot of discussion about trying to pin down the circumstances that will generate the trouble, the the leading theory is that IE 6 was simply not really well prepared for AJAX and as such, is a cross we must bear. Love to have you over there - it's a wide open forum so you can sign right in and comment. The more brains the better on this one! /p
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.
Just add Connection : close in the response header. The guess is that forcing a close will make IE clean up the connection properly and prevent stupid errors. It fixed all my problems with 12030.
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
Email: (optional, not displayed on site, gravatar enabled)
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.
you people seem to forget that these last years industrial web app's are becoming a big issue. Thousands of machines and machine part using web interfaces to display info. So iframes are still usefull where ajax has a lot of restrictions.
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.
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
Hey, I am checking this blog using the phone and this appears to be kind of odd. Thought you'd wish to know. This is a great write-up nevertheless, did not mess that up.

- David
Greetings, i'm a professional dancer. i'd like to see to make a showreel pertaining to my promotions. I also wish to use some animation. Can someone suggest me a superb animation studio, but certainly not very expensive? I'm here for 3 months for a tour.
www.petefreitag.com loads very slow, what is wrong?

Recent Entries


did you hack my cf?