#548 closed defect (fixed)
Mixed-Content warning in IE from BackgroundIFrame over HTTPS
Reported by: | Owned by: | bill | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Widgets | Version: | 0.2 |
Keywords: | Cc: | [email protected]…, [email protected]…, [email protected]… | |
Blocked By: | Blocking: |
Description
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!!!
Attachments (1)
Change History (27)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
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.
comment:3 Changed 16 years ago by
Milestone: | → 0.3release |
---|---|
Owner: | changed from anonymous to alex |
Status: | new → assigned |
comment:4 Changed 16 years ago by
It used to be about:blank but we changed it to javascript:void. See bug#427 for details.
comment:5 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
comment:6 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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
comment:7 Changed 16 years ago by
While my report is still valid, it may be obsolete at least for Tooltip: Tooltips work without BackgroundIFrame for me, see another Bugreport here
comment:8 Changed 16 years ago by
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!
comment:9 Changed 16 years ago by
Milestone: | 0.3release → 0.4 |
---|---|
Owner: | alex deleted |
Status: | reopened → new |
comment:11 Changed 16 years ago by
Summary: | Mixed-Content warning in IE when using dojo.widget.Tooltip over HTTPS → Mixed-Content warning in IE from BackgroundIFrame over HTTPS |
---|
comment:12 Changed 16 years ago by
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.
Changed 16 years ago by
Attachment: | dojo03_IE_Insecure.patch added |
---|
Patch against widget build to remove insecure content warnings for 0.3 in IE
comment:13 Changed 16 years ago by
Cc: | [email protected]… added |
---|---|
Owner: | set to bill |
Status: | new → assigned |
Thanks Dennis. We need you to sign the CLA first though (www.dojotoolkit.org/icla.txt). Then I can apply the patch.
comment:14 Changed 16 years ago by
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?
comment:15 Changed 16 years ago by
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 .
comment:16 Changed 16 years ago by
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
comment:17 Changed 16 years ago by
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;
comment:18 Changed 16 years ago by
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");' " +">";
comment:19 Changed 16 years ago by
FYI,
I have tried all the above fixes the system I am developing to no avail - I am still experiencing security warnings.
Lance
comment:20 Changed 16 years ago by
Cc: | [email protected]… added; [email protected]… removed |
---|---|
Milestone: | 0.4 → 0.3release |
Priority: | normal → high |
Type: | defect → enhancement |
Version: | 0.2 → 0.3 |
comment:21 Changed 16 years ago by
Cc: | [email protected]… added |
---|---|
Component: | General → Widgets |
Milestone: | 0.3release → 0.4 |
Priority: | high → normal |
Type: | enhancement → defect |
Version: | 0.3 → 0.2 |
Changing back property fields to correct values (as decided by dojo development team)
comment:22 Changed 16 years ago by
Cc: | [email protected]… added |
---|
comment:23 Changed 16 years ago by
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.
comment:24 Changed 16 years ago by
severity: | normal → blocker |
---|
comment:25 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Sorry! Wrong patch!
this one is correct: