Ticket #6603 (closed defect: fixed)

Opened 7 months ago

Last modified 5 months ago

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

Reported by: guest Owned by: peller
Priority: normal Milestone: 1.2
Component: Dijit Version: 1.1.0
Severity: normal Keywords:
Cc:

Description (last modified by bill) (diff)

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

  Changed 7 months ago by guest

That is IE version 6.0.2900.2180.xpsp_sp2_gdr.070277-2254

  Changed 7 months ago by bill

  • owner set to 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.)

  Changed 7 months ago by 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?

  Changed 7 months ago by bill

  • description modified (diff)
  • summary changed from Dialog on https page gives Do you want to display the nonsecure item? to Dialog on https page gives "Do you want to display the nonsecure item?" (IE)

IE7 also.... updating summary and description.

  Changed 7 months ago by becky

http://www.dojotoolkit.org/forum/dijit-dijit-0-9/dijit-support/dijit-1-1-wai-class-causing-ie-secure-nonsecure-mixed-content-er#comment-15552 provides a work-around

  Changed 7 months 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.

  Changed 7 months ago by 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)

follow-up: ↓ 9   Changed 6 months ago by bill

  • status changed from new to closed
  • resolution set to wontfix

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.

in reply to: ↑ 8   Changed 6 months 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.

  Changed 6 months ago by guest

  • status changed from closed to reopened
  • resolution deleted

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);

  Changed 6 months ago by 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?

  Changed 6 months 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".

  Changed 6 months 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

  Changed 5 months 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).

  Changed 5 months ago by bill

  • status changed from reopened to closed
  • resolution set to fixed

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

  Changed 5 months ago by peller

  • milestone set to 1.2
Note: See TracTickets for help on using tickets.