Mixed-Content warning in IE from BackgroundIFrame over HTTPS

[hannes.wyss@…]

This bug is similar to ​http://trac.dojotoolkit.org/ticket/427 While the page loads, a Mixed-Content warning is triggered for each instance of Tooltip.

In-Depth information: ​http://ajaxian.com/archives/ie-frame-bug

It appears that at least in IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 src="javascript.void()" is not sufficient to suppress the warnings. I am using a nightly build of dojotoolkit dated 2006-03-16.

I can work around this problem by following Anthony Garrett's suggestion and modifying dojo/src/html.js:

--- dojo/src/html.js.old        2006-03-21 15:55:14.739532041 +0100
+++ dojo/src/html.js    2006-03-21 15:55:25.301782644 +0100
@@ -877,7 +877,7 @@
 dojo.html.BackgroundIframe = function(node) {
        if(dojo.render.html.ie) {
                var html=
-                                "<iframe src='javascript:void(0)' "
+                                "<iframe "
                                +"style='position: absolute; left: 0px; top: 0px; width: 100%; height: 100%;"
                                +        "z-index: -1; filter:Alpha(Opacity="0");' "
                                +">";

Thanks for this great toolkit!!!

[hannes.wyss@…]

Sorry! Wrong patch!

this one is correct:

--- dojo/src/html.js.old        2006-03-21 15:55:14.739532041 +0100
+++ dojo/src/html.js    2006-03-21 16:01:48.186116294 +0100
@@ -877,8 +877,9 @@
 dojo.html.BackgroundIframe = function(node) {
        if(dojo.render.html.ie) {
                var html=
-                                "<iframe src='javascript:void(0)' "
-                               +"style='position: absolute; left: 0px; top: 0px; width: 100%; height: 100%;"
+                                "<iframe src='"
+                               + dojo.uri.dojoUri("blank.html")
+                               +"' style='position: absolute; left: 0px; top: 0px; width: 100%; height: 100%;"
                                +        "z-index: -1; filter:Alpha(Opacity="0");' "
                                +">";
                this.iframe = document.createElement(html);

[James Burke]

I wonder if it is just good enough to not specify the src attribute at all when there is an empty iframe:

<iframe style="whatever"></iframe>

If I recall correctly, I have seen that done before, and I think it works.

[bill]

It used to be about:blank but we changed it to javascript:void. See bug#427 for details.

[bill]

Sorry, I didn't read the bug description carefully enough. The originally proposed fix isn't "about:blank", but rather "blank.html", which solves the issue, but it tries to fetch an actual page called "blank.html", which is inefficient, even if there is no such page.

I removed the src argument from iframe. Hopefully that is sufficient. Fixed in #3359.

[Hannes Wyss <hannes.wyss@…>]

Please Apologize my not keeping in touch (I had sort of expected to get notifications automatically sent to my email, hence the long delay..)

I have tried the suggested fix (removing the src argument from iframe). Unfortunately this does not work - I still get the mixed content warnings.

Anything else I can do to help?

cheers Hannes

[Hannes Wyss <hannes.wyss@…>]

While my report is still valid, it may be obsolete at least for Tooltip: Tooltips work without BackgroundIFrame for me, see another Bugreport ​here

[martinc]

In my experience, referencing a blank.html file is the only thing that works reliably. Not specifying a 'src' attribute may seem more efficient, but it doesn't always work. I'd prefer slow but working to fast but broken!

[bill]

See also bug #717, where javascript: is suggested

[dennis.cartier@…]

I noticed this is still a problem in 0.3

I have created a patch to (hopefully) address it against the widget build. I am not sure if this will fix it everywhere, but it is a good start. If a maintainer could review it an apply the applicable bits I would appreciate it.

[dennis.cartier@…]

Patch against widget build to remove insecure content warnings for 0.3 in IE

[bill]

Thanks Dennis. We need you to sign the CLA first though (www.dojotoolkit.org/icla.txt). Then I can apply the patch.

[bill]

OK, I can't actually apply this patch file, because it's against a build version of dojo.js rather than against the source code, and because the demo engine code has changed, and for some reason the other patch files don't match up either. Can you try making a patch against the latest source code from SVN?

[ygdong]

do all above things,and i use the demos/Tree/tree.html with https,but i still get a Mixed-Content warning .if i reomve line 246 to 252,it's ok. why? who can help me? it's mean: i can't static create tow or more level tree .

[martin@…]

just replace "<iframe " by "<iframe src='" + dojo.hostenv.getBaseScriptUri() + "blank.html' "

No src cause SSL Security Warning.. javascript:void(0); doesn't work for me with src it works correctly with all browser

[michael.mckibben@…]

OK, I ran into the same issue with IE (version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519) with dojo-0.3.1 and I was able to fix the problem by setting the src attribute on the iframe DOM node to null (e.g. 'iframe.src = null;') Here is a context diff made from the latest code pulled from the svn repository:

$ svn diff
Index: src/html/extras.js
===================================================================
--- src/html/extras.js  (revision 4479)
+++ src/html/extras.js  (working copy)
@@ -351,6 +351,7 @@
                                +">";
                this.iframe = document.createElement(html);
                this.iframe.tabIndex = -1; // Magic to prevent iframe from getting focus on tab keypress - as style didnt work.
+               this.iframe.src = null; // prevent Mixed Content warning with SSL
                if(node){
                        node.appendChild(this.iframe);
                        this.domNode=node;

[michael.mckibben@…]

Spoke too soon. My previous suggestion works, but unfortunately it also has the side effect of attempting to load 'null' from the web server. However, setting the src to 'javascript:false' works and doesn't attempt to load a bogus page. Note: 'javascript:false' works, but 'javascript:void(0)' doesn't. Here is an updated diff output of my workaround.

$ svn diff
Index: src/html/extras.js
===================================================================
--- src/html/extras.js  (revision 4479)
+++ src/html/extras.js  (working copy)
@@ -345,7 +345,7 @@
 dojo.html.BackgroundIframe = function(node) {
        if(dojo.render.html.ie55 || dojo.render.html.ie60) {
                var html=
-                                "<iframe "
+                                "<iframe src='javascript:false' "
                                +"style='position: absolute; left: 0px; top: 0px; width: 100%; height: 100%;"
                                +        "z-index: -1; filter:Alpha(Opacity="0");' "
                                +">";

[Lance Duivenbode (dojo AT duivenbode DOT id DOT au)]

FYI,

I have tried all the above fixes the system I am developing to no avail - I am still experiencing security warnings.

Lance

[bill]

Changing back property fields to correct values (as decided by dojo development team)

[terry.field@…]

FWIW, this is what we are currently doing to solve the problem:

var html="<iframe "
  + "style='position: absolute; left: 0px; top: 0px; width: 100%; height: 100%;"
  +        "z-index: -1; filter:Alpha(Opacity="0");' ";
if (window.location.protocol == "https:")
  html += "src="" + dojo.uri.dojoUri("blank.html") + "" ";
html += ">";

This at least stops the unnecessary GET for non-SSL traffic. For SSL traffic, a tiny 'blank.html' file could be supplied and excessive GETs controlled by server-side cache management through http header control. We are doing this in practice and it appears to be working well.

Just another option.

[bill]

(In [6212]) Fixes #548

[(none)]

Milestone 0.4 deleted