Tuesday, June 21st, 2005

IE Frame Bug

Category: Editorial, IE

Bob Lee brought up a sneaky little IE bug:

Some of my IE users were seeing a, “mixed secure and insecure content,” warning. After looking everywhere for a style sheet, web page, image or script loaded via HTTP instead of HTTPS, I tracked the problem down to an iframe missing the src attribute (the attribute was set dynamically later on by Javascript). The correct solution is not for the client to lower their security settings. Mixing insecure (HTTP) and secure (HTTPS) content can defeat the security of the secure content. A truly secure web site should use HTTPS from the first page to the last and not cut security corners for the sake of performance. You can work around the issue by setting the src attribute to a blank page instead (this results in one more request, but it’s a lot less annoying than the warning).

Posted by Dion Almaer at 1:15 pm
9 Comments

+++--
3.2 rating from 22 votes

9 Comments »

Comments feed

There is a better possibility to work around this bug. In qooxdoo (http://qooxdoo.sourceforge.net), our new open-source javascript based gui toolkit, we use the following as our initial source:

javascript:void(0)

This works like charm and omit the additional server request.

Comment by Sebastian Werner — June 21, 2005

@Eric:

we have not yet any problems with this solution. Could you mention some details on your mixed results? Thank you.

Comment by Sebastian Werner — June 21, 2005

Wish I could remember the details (it’s been nearly a year now). Seems like the original problem stemmed from our dynamically adding the iframe at runtime on the client. I recall that using javascript:void(0) in that scenario worked in-house but not after deployment to our client, and we suspected different IE versions. We then switched to serving the page with the iframe already included and encountered a similar problem with a javascript:void(0) src, and so then switched to using a blank.html src. I may have the order of these events wrong. In any case, the results (and approaches, and IE versions) were mixed, and in the end the use of an actual src proved to be the most robust solution.

Comment by Eric W. Bachtal — June 22, 2005

I’ve come across a similar bug in IE when submitting a file attachment via SSL using a frame or window as a target. For example:

<form method=”post” enctype=”multipart/form-data”
target=”attachmentFrame” action=”https://myserver.domain.com”>

Description: <input type=”text” name=”description” value=””><br>
File: <input type=”file” size=20 name=”fname”>
<input type=Submit value=Upload>
</form>

<iframe id=”attachmentFrame” name=”attachmentFrame” src=”https://myserver.domain.com/blank.html”></iframe>

This will (intermittently) cause IE to pop up the mixed content warnings. I have yet to figure out why. There is always a “src” attribute on the IFRAME, and it never changes from the “https” protocol. From the server perspective – when it fails, IE sends the HTTP headers (including the content-length) but never sends the body of the POST. (Sorry if this comment doesn’t format properly)

Comment by Marc Novakowski — June 24, 2005

I had the same problem that I thought I had solved using javascript:void(); but that proved to be unreliable when deployed. I hadn’t wanted to go the route of having a real blank page because it added a usually pointless file (most instances won’t be using SSL) to the deployment package. Then I heard that once IE has checked the URL syntax resolves within the same server, the file doesn’t have to exist! That gave me a simple and robust solution: Use src=”blank.html”, but no extra file to deploy.

Comment by Anthony Garrett — February 9, 2006

there was a problem a few days away with myspace sites. no pics were being displayed. how do i fix this?
thank you,

Comment by sophia sakellarios — August 17, 2006

Very interesting post! Thanks for sharing this. I’m tracking down a different bug with dynamically set iframe src attributes in IE, but this is something I need to consider in the back of my mind while I do it.

Comment by Forrest — October 11, 2007

Sorry to bring this back up. The src=”javascript:false” worked for me in IE, but it’s been causing security errors in Chrome. Does anyone know if there’s a work-around without having set src to a secure page?

Comment by thirdender — June 23, 2009

Follow up to my comment: Apparently I’d fixed the problem, but Chrome remembers what sites are insecure until after you’ve restarted the browser. Chrome actually had a message helping me find exactly what the security problem was (I was trying to set an onload handler for an insecure IFRAME). The message disappeared after I fixed the problem, but the security warning remained. Simple solution: restart Chrome.

Comment by thirdender — June 23, 2009

Leave a comment

You must be logged in to post a comment.