Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#6603 closed defect (fixed)

Dialog on https page gives "Do you want to display the nonsecure item?" (IE)

Reported by: guest Owned by: Adam Peller
Priority: high Milestone: 1.2
Component: Dijit Version: 1.1.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

Just include the dialog support on a https based website, and you will see the warning if using IE6/IE7.

Using IE6/IE7 give this warning "Do you want to display the nonsecure item?"

FF2 does not give the warning.

With a current nightly build (april 22, 2008)

Could be the iframe created by the dialog code with a src = javscript:"" ?

<html>
<head>
<script type="text/javascript" language="JavaScript" src="dojotoolkit/dojo/dojo.js"></script>
<script type="text/javascript" language="JavaScript">
            dojo.require("dijit.Dialog");
</script>
</head>
<body>
</body>
</html>

Change History (16)

comment:1 Changed 12 years ago by guest

That is IE version 6.0.2900.2180.xpsp_sp2_gdr.070277-2254

comment:2 Changed 12 years ago by bill

Owner: set to Adam Peller

To bug reporter:

Thanks for the test case. I was able to reproduce this using your test case although strangely test_Dialog.html works fine.

You could probably work around this problem by doing a build.

To Adam:

Looks like the culprit is in Dialog.js:

dojo.requireLocalization("dijit", "common");

Delete everything in Dialog.js below that line, and the error still occurs. Delete that line and the error goes away.

I bet it's got something to do w/the fact that nls/en/loading.js and nls/en-us/loading.js don't exist although I haven't tested it. (And thus it also seems like an IE bug that it's displaying that warning because of a 404.)

comment:3 Changed 12 years ago by Adam Peller

makes me wonder if it's actually complaining about the 404 error page... doesn't IE go fetch some link farm page in that case? I'd say this is a wont fix, since we can't do much about this and the user can avoid the problem with a build. Is it IE6 only?

comment:4 Changed 12 years ago by bill

Description: modified (diff)
Summary: Dialog on https page gives Do you want to display the nonsecure item?Dialog on https page gives "Do you want to display the nonsecure item?" (IE)

IE7 also.... updating summary and description.

comment:6 Changed 12 years ago by bill

Ah cool, quoting from there:

The work-around for this problem is to specify the absolute URL (with the leading https://) in the initial Dojo library load. For instance:

<script type="text/javascript" src="https://www.foo.com/js/dojo/1.1.0/dojo/dojo.js"></script>

Nice easy workaround.

comment:7 Changed 12 years ago by Adam Peller

can anyone confirm whether the 404s are actually made to the https: server, or whether it's just the security code confusing the protocols? If the former, then we'd not only get the security warning, but possibly the wrong results. If the latter, we should probably just wontfix this with the workaround (thanks, Nicole)

comment:8 Changed 12 years ago by bill

Resolution: wontfix
Status: newclosed

I'm not sure what you mean. The 404s are responses from the server running dojo, the same server that processes all the other https requests.

I ran fiddler to see if IE is trying to pull a "page not found" error page from somewhere else but it didn't report anything. But perhaps it's pulling it from the file system?

In any case the workaround avoids the problem (of course we still get the 404s but there's no warning dialog), so I'm closing this as wontfix.

comment:9 in reply to:  8 Changed 12 years ago by guest

Is there a way to fix this issue other than this workaround? Requiring a user to put the absolute path to the dojo library is not an elegant solution as many users have multiple environments to which the dojo library is published (e.g. different domains, production/dev/testing). To have to change everytime the application is deployed to a new domain is cumbersome.

comment:10 Changed 12 years ago by guest

Resolution: wontfix
Status: closedreopened

Ok it seems if one wraps the deletion of the test node during the detection of high contrast mode in a timeout, it gives IE enough time to realize that nothing is wrong with the background image when removeChild is called (see http://support.microsoft.com/kb/925014 and dijit.wai.onload).

The following should be added in place of the current removeChild call:

			setTimeout(dojo.hitch(this, function(){
				dojo.body().removeChild(div);
			}),100);

comment:11 Changed 12 years ago by Adam Peller

what about the two methods cited in the MS knowledge base? (outerhtml and css background) Might those be easier or "safer"? Is this the same issue as the loading.js 404s? Guest, can you identify yourself?

comment:12 Changed 11 years ago by guest

My name is Julian. I suppose the css change would be the "cleanest or safest". I simply didn't have time to play around with it. Here are the changes required if one decided to go that route:

Script in place of current 'div.style.cssTest="..."':

		dojo.addClass(div, "diji_a11y_test_node");

Css Class in dijit.css:

.diji_a11y_test_node{
	border: 1px solid;
	border-color:red green;
	position: absolute;
	height: 5px;
	top: -999px;
	background-image: url('../../dojo/resources/blank.gif');	
}

This is probably better than my previous example as the comments in the dijit.wai.onload function specifically state not to use the "this" variable. Also, I found this solution thanks to sgoldenberg's MS link in the forum thread "Dijit 1.1 wai class causing IE "secure/nonsecure" mixed content error".

comment:13 Changed 11 years ago by guest

Sorry, I forgot to mention that I have no idea if it is related to the "404" issue mentioned above. I don't receive any other warnings in IE 7.0.6000.16681 on Vista when I apply my above mentioned patch.

  • Julian

comment:14 Changed 11 years ago by bill

I guess there's more than one problem related to these mixed-content warnings.

Is there a way to fix this issue other than this workaround?

The other way to avoid the original problem, about 404s, is to do a build.

http://support.microsoft.com/kb/925014

That's certainly interesting. As per the suggested solution about CSS classes though, see #3416. The style info used to be in a CSS file but then was inlined for fear that maybe dijit.css might not have finished loading yet. So probably it's better to do the outerHTML thing (for IE).

comment:15 Changed 11 years ago by bill

Resolution: fixed
Status: reopenedclosed

(In [14121]) Workaround for mixed-content warning on IE due to deleting element w/background-image. Fixes #6603. !strict

comment:16 Changed 11 years ago by Adam Peller

Milestone: 1.2
Note: See TracTickets for help on using tickets.