Download and Buy Now Link

Even more problems with the IE 8 mixed content warning

September 17, 2009

We have previously written about the pointless and confusing ‘Do you want to view only the webpage content that was delivered securely‘ message in IE 8. It is displayed by default when a secure web page attempts to use non-secure content such as images, javascript or CSS. That post has been so popular that it attracts 40% of the traffic to this blog.

The IE 8 mixed content dialog is pointless because 99.9% of web users just want it to go away and let them get on with what they were doing. For the 0.1% of web surfers who do care, it is confusing because of the way it is worded:

IE 8 Security Warning

The blog post described how you can disable this warning and from the comments it looks like many users are now doing this.

Even if you do this, IE still silently performs the check and hides the re-assuring padlock icon that you normally see on HTTPS pages:

No Padlock icon when mixed content present

This could be disturbing for anyone on a checkout page who is about to enter their credit card details. So if you’re web site developer you really need to avoid using mixed content – even for users who have disabled this warning. Firefox has the mixed content warning turned off by default. Let’s hope Microsoft do the same turn in the next version of IE.

You can normally fix the mixed content warning by ensuring that all the content on a secure page is served up with HTTPS. In HttpWatch you can quickly check a page by using a forced refresh to look for URLs starting with ‘http;’ :

Mixed Content in HttpWatch

However, a customer contacted us recently because they were still getting the mixed content warning even though they had no HTTP URLs on their secure page. After some investigation it was found that this commonly used javascript technique was causing the problem:

// Causes mixed content message in IE on a secure page
document.write("<script id="__ie_onload" src="javascript:void(0)"></script>");
document.getElementById("__ie_onload").onreadystatechange = function()
{
     if (this.readyState == "complete") domReady();
};

It’s a trick used to emulate a DOMContentLoaded event in IE.  A security warning occurs because of the use the “javascript:” protocol even though no download occurs.

The fix is to use //: in the src attribute in the same way as popular javascript libraries such as jQuery and prototype. This does cause a harmless ERROR_INVALID_URL entry in HttpWatch, but it avoids the mixed content message:

// Does not cause a mixed content message in IE on a secure page
document.write("<script id="__ie_onload" src="//:"></script>");
document.getElementById("__ie_onload").onreadystatechange = function()
{
     if (this.readyState == "complete") domReady();
};

29 Comments

  • Pingback: IE7, removeChild and SSL = IE7 mixed content warning Pelago :: web design, web development blog ::

  • Thank you THANK YOU! Our problem was with a Movable Type installation. The cause of our security warning was the __ie_onload trick. At first we didn’t find it because in our code, the javascript:void(0) isn’t surrounded by double-quotes, so searching for src=”javascript yeilded nothing. But we found it, and replaced the src attribute with “//:” and it now works fine. Seems like a crazy work around – but thank you 100 million for posting this. How on earth you found it…I don’t even want to guess.

  • Thanks httpwatch for this wonderful software to detect my http references in https page. i had same problem of security message. my https page did not have any http reference and it was working fine in IE7, and mozila, but testing in IE8 gave me security warning message. using httpwatch i could come to know that following 2 auto generated files(scripts) by .Net were having http refereces (in view source of the page they displayed with relative path so did not get detected as http reference but httpwatch found them as http references:))
    1.WebResource.axd(related to js) 2.ScriptResource.axd (related to ajax). i kept both this files in web.config sucure page collection list as below

    and now page works fine in IE8 without Security message. Thnx a ton httpwatch n its Team :)

  • This is for .Net developers who are having security message problem —
    this message is due to mixed(http+https) content on the page. please make sure that ur https page contains only https content on the https page.

    i had same problem of security message. my https page did not have any http reference and it was working fine in IE7, and mozila, but testing in IE8 gave me security warning message. using httpwatch i could come to know that following 2 auto generated files(scripts) by .Net were having http refereces (in view source of the page they displayed with relative path so did not get detected as http reference but httpwatch found them as http references:))
    1.WebResource.axd(related to js) 2.ScriptResource.axd (related to ajax). i kept both this files in web.config sucure page collection list as below

    and now page works fine in IE8 without Security message. Thnx a ton httpwatch n its Team :)
    Reference Link : http://blog.httpwatch.com/
    using this software you can find all http references in https page.

  • We are experiencing the same issue for a client, but only for the FIRST session with the browser. Subsequent sessions do not incur the error.

    This only happens in IE 8. Did any of you see that behavior, where the error occurred, but then went away on subsequent sessions?

    Thanks

    Jerry

  • Whenever I go onto Facebook and click on Privacy Settings and then Search, it looks like everything is working properly. But then that message pops up and the search tool doesnt work.
    How can I fix the problem?? Please help, as I would like to be able to use the search engine to look for people

  • Just not having mixed content anymore is NOT an acceptable solution!

    We have SSL-secured web applications running for our customers where the content managers are able to add rss feeds. For performce reasons we load these feeds dynamically with clientside javascript. Our thrustworthy customers use thrustworthy feeds from thrustworthy sources.

    Yet IE8 thinks it knows better and warns us… doh!

    I think Microsoft should fix this before losing more and more users to FireFox and Chrome…

  • Thank you. This was driving me crazy. In the process of trying to find the answer, I found that GeoTrust’s SSL badge was sending http: posts on every page load, but removing it didn’t make the warning go away. Then I removed Google Urchin, which was https, but was the only external link left, and still it popped up.

  • There is another reason for this that I just discovered. jQuery uses “innerHtml” for .remove(), .html(), .empty(), etc. “innerHtml” will cause a mixed content warning in IE. One quick fix is to hide the current content using $(elem).contents().css(“display”,”none”) then append new content.

  • There’s another IE bug, which shows mixed content error.
    We have in our application link like following:
    String url = ‘/application/processImage.do?img=path/to/image.png’;

    IE fails with this link, and shows mixed content error. Problematic is img parameter, which contains path to file and file name with extension… There are two workarounds for this:
    1. make url absolute (use javascript, to avoid hardcoded strings)
    String url = location.protocol + ‘//’ + location.domain + ‘/application/processImage.do?img=path/to/image.png’;

    2. add another parameter at the end of url:
    String url = ‘/application/processImage.do?img=path/to/image.png&anotherParameter=value’;

    Mixed content message is not shown anymore.

  • I’ve just found yet another reason of this error.

    On the page loaded via HTTPS I had an swf. It has been embedded using Macromedia’s library called JavaScript Integration Kit – and specifically by means of FlashTag helper class:

    var chartSwf = new FlashTag(‘../swf/chart.swf’, “100%”, “330″, “7,0,14,0″);
    chartSwf.write(document);

    The trick is in the FlashTag implementation – when embedding swf during write() call, it sets the object codebase to http://download.macromedia.com/

    After I changed all http references to https in Macromedia’s JavaScriptFlashGateway.js, the error went away. So even though there was no call to http happening at all, it seems that just setting codebase to http is enough for IE8 to display this message.

    This one was particularry tricky to find out because there was nothing in the http logs – no access, no javascript: call etc…

  • Pingback: IE 8 Mixed content warning…. but everything loads as HTTPS, I’m sure « Eric's Collection

  • This is really stupid, because enabling mixed content for trusted zone only doesn’t work. To get rid of the warning, you have enable mixed content for the entire Internet zone. This is of course opening you up to the security risk the warning is supposed to protect you from!

  • Thank you very much! The mixed-mode warning had been plaguing us for months. The issue detailed above was the culprit. Thanks again!

  • Another thanks from me! I used this article to fix this.

    One odd thing though, the MC dialog returns when I’m using the IE8 debugger (F12). Anyone any ideas?

  • Fantastic Blog!
    Question: We run into a problem once in a while where certain (not all) IE7 and IE8 users will get a security warning on our website. The users do not have the same problem in FF or Chrome. We have never been able to reproduce the errors on any of our machines. Any thoughts to certain client conditions that will produce:
    Security Certificate Warning the site is insecure….

    I guess the basic question is are there any know best practices to make your site as compatible as possible with the IE7, IE8 Security quirks?

    Any suggestions would be appreciated.
    Thank you.
    -andy

  • Hello, we have a .js file that is causing the IE 8 mixed content warning, I see a fix up there from “C”.. but I really need more details if anyone can elaborate on what he said. Our file has the innerhtml like “remove(), .html()” etc. and it is stated above that this can cause the IE 8 error, if anyone has a detailed fix to build on “C”s statement, like a code snippet, that would be WONDERFUL!.

  • My answer is for ANDY B above. YES ANDY there are settngs in Internet Explorer that can make this error message to not show up.
    1.Going to Tools->Internet Options->Security
    2.Select the ‘Security’ tab
    3.Click the ‘Custom Level’ button
    4.In the ‘Miscellaneous’ section change “Display mixed content” to Enable

  • Fantastic blog…thanks a lot guys for adding so much of information.
    Initially I was looking for the http content using fiddler and httpwatch but couldn’t find it then came across to this blog and it opened my eyes.
    With your information I could find that the issue on my side was because of the following tag -

    link rel=’stylesheet’ type=’text/css’ href=’/banking/media/styles/css/abcd.css’

    Although it was fetching using HTTPS it was causing issue and I had to change it to something like following to make it working.

    link rel=’stylesheet’ type=’text/css’ href=’https://127.0.0.1:9445/banking/media/styles/css/abcd.css’

  • Regarding ie8 with ie7 browser mode on, and inline style background:

    $(document).ready(function() {
    // ie8 with ie7 browser mode
    $(‘#mytest’).append(‘foo’); // security warning
    //document.getElementById(‘mytest’).innerHTML = ‘foo’; // no security warning
    })

  • It is really a good one. I just submitted this article to my boss. So finally he understood that this is ie browser issue. Thanks once again.

  • Found that my use of a jquery plugin called File Style was causing this mixed content warning (it does a background image removal)

  • Here is yet another instance where IE will throw the mixed content warning.

    * You are on https
    * You have a piece of content that is added dynamically with innerHTML()
    * That dynamic content has a css background image that is referenced using using the “back directory” syntax, like url(“../path/to/image”)

    Apparently IE8 doesn’t the ‘../’ reference. We switched to an absolute URL and that fixed the issue for us.

    This applies to any functions that wrap innerHTML() like jquery’s empty().