Skip navigation.

Choosing a JavaScript Toolkit For Serious DOM ManipulationAll recent postsBook Review: Programming Windows Workflow Foundation

Always Set The Source of IFrame Content (iframe.src)

When I wrote the always-centered AJAX progress indicator (available here), I made a n00bie mistake of not setting the iframe.src attribute. It bit us in the butt when a page served over SSL began to popup that ubiquitous dialog “This page contains both secure and nonsecure items. Do you want to display the nonsecure items?” To make matters worse, IE 7 didn’t complain. IE 6 did.

After some bug chasing, we narrowed the search to this code:

if (progressContainer.getElementsByTagName ('IFRAME').length == 0) {
   var frameKludge = document.createElement ('iframe');
   progressContainer.appendChild (frameKludge);
}

It turns out, there’s a Microsoft KB article which talks precisely about this problem.

Symptoms: This occurs when the page contains an IFRAME that does not specify a SRC attribute.

Cause: Microsoft Internet Explorer is unable to determine if the SRC attribute of the IFRAME is secure or unsecure.

Resolution: To resolve this problem for a page that will be downloaded through SSL, set the SRC attribute of the IFRAME. If the IFRAME is not expected to have a SRC attribute initially, point the IFRAME to a dummy HTML page.

So the iframe wants a dummy source. Fine.

if (progressContainer.getElementsByTagName ('IFRAME').length == 0) {
  var frameKludge = document.createElement ('iframe');
  // Workaround: http://support.microsoft.com/kb/261188
  frameKludge.src = "blank__.htm" "about:blank";
  progressContainer.appendChild (frameKludge);
}

Problem solved, it seems. My only peeve with this workaround is that you now get a 404 on the dummy page. You win some, you lose some.

Download updated code here (same link as before).

Aug 8, 2007, update: Looks like a dummy page can cause trouble in more ways than one. As Jamal suggested below, I’m going to give ’about:blank’ a try. Please try the updated code and let me know of any problems.

Aug 8, 2007, update: Alright, ’about:blank’ doesn’t solve the problem. The warning still pops up. Apparently, it’s not good enough for IE. I think the best of both worlds is to create an almost blank page and have the iframe point to it.

By the way, pointing to that KB article at Microsoft doesn’t work because you’ll be serving a non-secure page within a secure one. Besdies, some scripts on that page throw client-side errors.

Comments

Comment permalink 1 Jamal |
use "about:blank" for the source to avoid the 404's
Comment permalink 2 pauldwaite |
> "use "about:blank" for the source to avoid the 404's"

Would that work in all browsers?

Would an empty HTML page on the server be practicable?
Comment permalink 3 Steven Smith |
Use this URL for your dummy page:
http://support.microsoft.com/kb/261188

Let MS pay for the bandwidth and if anybody wonders why the page is there, they can read the KB article...
Comment permalink 4 Kyle |
I use src="javascript:false;". Works fine in IE6, IE7 and FF. Luckily I don't have to worry about other browsers, so maybe it won't work for you.
Comment permalink 5 Rory Fitzpatrick |
Using blank__.htm on a secured application causes a recursive load of the login page (ie the server gives a 302 redirect to the login page, which tries to run the script again, which tries to load blank__.htm again which redirects again etc. etc.)
Comment permalink 6 Milan Negovan |
Hmmm... Indeed, this can be a problem. I guess it's worth trying 'about:blank' as Jamal suggested. I've updated the code.
Comment permalink 7 Josh Stodola |
This bit me last week (one day before this post was made, ironically). I missed it before deployment becuase I didn't test my iFrame functionality in IE6.

I just went ahead and created an actual dummy HTML page with a big "Please Wait" heading message on it. Worked perfectly for me because my particular iFrame gets made visible and has its location dynamically set using Javascript. Perfect!
Comment permalink 8 Josh Stodola |
I take that back, I did test it in IE6. However, in development we were not going over SSL (obviously).
Comment permalink 9 jim |
Hi, how is this progress update different than the one from ASP.NET AJAX Toolkit.

I downloaded your zip file. It seems there are more codes neccessary to do just the ProgressUpdate. With AJAX Toolkit, it is only a few lines of codes to do what you said in this article.

Are there any benefit with your progressUpdate?
Comment permalink 10 Milan Negovan |
Jim, I'm sorry, which control in the AJAX toolkit did you mean? There's an UpdatePanelAnimation, but it's not the same. Here's the reason (and a follow-up) I wrote mine.
Comment permalink 11 Wolfy |
The PopupExtender in the AjaxControlToolkit uses:

theIFrame.src = "javascript:'|html>|/html>';"

where |s are less-than signs, enclosing the html tags.

Useful article, by the way. Just struggling to get the 'background' behind the progress indicator to be greyed out and read-only, similar to the ModalPopup control's behaviour in the Toolkit. Any tips?
Comment permalink 12 Milan Negovan |
I haven't really tried the "gray-out" effect. Things like Lightbox use it, so that's a good place to look.
Comment permalink 13 JS |
Nice. The javascript: in the src works great and doesn't cause permission problems when you open and rewrite the iframe's document.

Emails and Notifications

Would you like to be notified when somebody responds to this post?  Would you like to have these comments emailed to you?

Submit your comment

Please enter only text since all HTML tags except hyperlinks will be stripped. Hyperlinks will become live links. Any comments with flaming or offensive language will be deleted. Be courteous to other posters. Thank you.

Your name (required):
Your email (optional):
Your site's URL (optional):
Enter this number
Type in the number above:
Comment (required):