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

Posted on August 03, 2007  |  

Posted in Development

13 comments

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.

13 comments

Jamal
on August 3, 2007

use "about:blank" for the source to avoid the 404's


pauldwaite
on August 4, 2007

> "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?


Steven Smith
on August 4, 2007

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...


Kyle
on August 6, 2007

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.


Rory Fitzpatrick
on August 8, 2007

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.)


Milan Negovan
on August 8, 2007

Hmmm... Indeed, this can be a problem. I guess it's worth trying 'about:blank' as Jamal suggested. I've updated the code.


Josh Stodola
on August 9, 2007

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!


Josh Stodola
on August 9, 2007

I take that back, I did test it in IE6. However, in development we were not going over SSL (obviously).


jim
on September 27, 2007

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?


Milan Negovan
on September 27, 2007

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.


Wolfy
on August 18, 2008

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?


Milan Negovan
on August 19, 2008

I haven't really tried the "gray-out" effect. Things like Lightbox use it, so that's a good place to look.


JS
on April 3, 2009

Nice. The javascript: in the src works great and doesn't cause permission problems when you open and rewrite the iframe's document.