Sometimes debugging web applications in Microsoft Internet Explorer or Microsoft Edge browsers can drive people insane. I was recently working with a team at a client where we deployed a Meteor based application. We had validated the functional behavior in IBM and were confident that it would meet the client’s needs. However within the client’s network we noticed inconsistent behavior when using Microsoft Internet Explorer 11. Before I go on I wanted to highlight the contribution of the IBM team here: Alfonso Jara, Daniel Padron, Leonardo Faccio Demo and Juan Antonio Albarran.
Using Mozilla Firefox or Google Chrome worked absolutely fine. After some thorough investigation we finally realised what was going on here. Within the client’s network, Internet Explorer 11 was configured to use a proxy. Our application was deployed on one of the domains that would trigger bypassing the proxy, say webapp.some.domain. We had already found that disabling the proxy configuration in Internet Explorer all together resolved the functional issues in the application. The configuration was done through a proxy .pac configuration file, which defines to bypass that proxy for certain domains including some.domain:
function FindProxyForURL(url, host)
{
// .PAC PRB Version 2.2i (iRule)
var lhost = host.toLowerCase();
host = lhost;
// Direct connections to intranet domains
if (dnsDomainIs(host, "localhost") || dnsDomainIs(host, "some.domain")
{
return "DIRECT";
}
// Use proxy for all other public sites
return "PROXY public.proxy.domain:8080"
}
According to this documentation Internet Explorer 11 considers any web site in a domain that bypasses the proxy as an ‘intranet’ site. This applied to our web application when we had the proxy configuration enabled. Crucially, by default any intranet site is rendered in Internet Explorer 7 ‘compatibility view’. This is what was happening when accessing our web application, which had only been designed and tested for Internet Explorer 8 and higher (and did not support Internet Explorer 7). We had not noticed the behavior described here until we enabled debug mode using F12 and noticed that every time we would access our web application it would show a ‘7’ as shown below:

Fortunately you can force Internet Explorer 11 to not render intranet web sites in Internet Explorer 7 compatibility view. When we disabled the option ‘Display intranet sites in Compatibility View’, our web application magically started to work fine!

However this was of course not a viable solution, as we would had to change the default configuration of Internet Explorer 7 across all workstation within the client. According the Microsoft documentation, you can also signal to the web browser to not render a page in Internet Explorer 7 compatibility mode regardless of the client configuration. There are two mechanisms: either set the X-UA-Compatible meta tag in the HTML body of the page response, or set an HTTP response header. When examining our web application, we noticed that we were already setting the the X-UA-Compatible meta tag in the HTML body of every page.

But the devil is in the detail. As documented here, the X-UA-Compatible meta tag must be the first tag following the <HEAD> tag in the HTML body.
The X-UA-Compatible meta tag must appear straight after the title in the
<head>element. No other meta tags, css links and js scripts calls can be placed before it.
We made a simple change resulting in the HTML code listed below, which resolved our issue once and for all!

Now even without disabling the ‘Display intranet sites in Compatibility View’ option in Internet Explorer 11, our web application rendered perfectly fine in Internet Explorer 11. The moral of this story is that once you understand the root cause of your problem, finding a solution can be very straightforward. I decided to write this blog post in the hope that this will save someone else some time and headache elsewhere!
Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 13 July 2018 (5596 visits)