Ajax: IE IFrame 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).
10 Comments:
I guess the bug must result from IE actually loading an internal empty page (about:blank?), which is not secure, and it doesnt check that it shouldnt count as an actual page loaded in the iirame.
Thanks, Bob. This post was very helpful diagnosing problems using the autocompleter from the script.aculo.us and prototype javascript libraries on IE over https (SSL). I just had to change their src="javascript:" to src="actualPage.asp" and it worked.
Thanks for posting this.
Try this:
src="javascript:false;"
I am only including the prototype script and I cannot find any iframe tags inside of it but I still get the errors. Any thoughts?
If you load your page using HTTPS, you must also load the prototype script using HTTPS.
The script is being loaded with an https:// beginning.
You might use a debugging proxy to watch the requests.
I used fiddler and saw that there was a request to "/" with an IP of 0.0.0.0 that came up red. There is a script call on about line 3988 that goes
document.write("script id=_onDOMContentLoaded defer src=//:
I didn't know if this was an empty call for the src and the javascript fills it in later or what.
http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/7daae29348b1c258?hl=en
Sorry, hit the submit button before I added comments. Another user found that a piece of code for detecting if DOM was loaded for IE was what was causing it. Since we're not using that part, I commented out the code and everything is good to go. I also got a message from the prototype guys that the next version will run differently to detect DOM for IE to fix the issue. Thanks for all of your help.
Post a Comment
<< Home