alanwilliamson

Fix for IE using an AJAX/DHTML driven upload progress monitor

You think you're going well with your web development until you go and try your site out on Internet Explorer, then you discover just how much work you have still to do.

One of the biggest draw backs with browsers is that while they are very good at bringing data to you, they are very bad at pushing data away from you.  Still, even today with all the browser optimizations and what have you, there is no suitable upload progress feedback from either FireFox or IE.  Even something in the status bar would go a long way to letting the user know stuff is still happenning.

While we wait for such a innovation, you can instead employ a nice DHTML alternative, suggested by Steven Smiles.  This is a neat trick to give feedback to the user on the progress of the upload by polling the server to see how much it has received.  The major downside to this approach is that it requires some modification on the server side script to monitor the progress and it adds a lot more requests to your server while it sits there polling asking the same question "well, are you done yet?".

IE SecurityI instead opted not to go to this route but instead provide a little animation of an uploading graphic, with some explanation as to why stuff can sometimes take a while to upload.  You know, something for the user to read as soon as they submit the file upload instead of letting them watch a blank window.

This is achieved using a hidden IFRAME.  When the upload script is done, it makes a call back to the parent window saying it is now done.  This all works beautifully if you are uploading to the same server that your page is on.  However, IE coughs when it is on a different server.

At Blog-City, as like many others, we use a separate set of servers for handling user files. So they would never be uploading to the same machine that is running the core web application.  IE would submit the file upload to a different server (to a hidden IFRAME), and once completed it would do a target'ed form submit() to a script back on the main web application server.

At this point IE would throw up its popup blocker and start a whole series of security moaning.  Now it shouldn't be, as the page that is actually triggering the client side Javascript call is coming from the same server that loaded the whole page.

The problem stems from the fact that the form is explicitly target'ed.  This seems to reset the security policy from IE.  Instead, simply drop the target attribute from the form and submit it back to the IFRAME and all is well again.

It is important that the IFRAME you are submitting back to has actually been used before at some point in this transaction.  If not, then IE will see it as a phishing attempt and present the user with a whole host of nasty looking warnings.

Fun Fun Fun.


 

Recent Cloud posts

Recent JAVA posts

Latest CFML posts


 
Site Links