IE Browser Compatibility Mode – part 1

Recently my team ran into an issue where some of our clients were getting odd script errors when accessing the web application. To make matters a little more confusing, these errors appeared to only occur in instances where our clients were accessing the website from another application – hence the functionality of browsing to our website was being handled within a process outside of a standalone browser.

So, we had clients using the same version of a third party tool, hitting the same version of our application, and some getting errors, and some not. Why? What was different?

In the end it turned out to be related to IE and its Compatibility Mode. But not in the way that most people think of when looking at browser compatibility – and certainly not what we expected.

Internet Explorer. Love it. Hate it. Either way, it’s something that needs to be accounted for when developing web pages. While it’s not the only browser that needs to be considered when looking at compatibility, it is the one that seems to be picked on the most.

First off – What is Browser compatibility? Simply put: it is the ability/flexibility of a website or web application to function across different browsers and degrade gracefully when browser features are absent or lacking.

Now, the intent of this series is to look at the IE Browser Compatibility View settings to better understand the different options, and what it means for you, as a developer.

As such, the larger topic of Cross-Browser Compatibility is better covered elsewhere on the web – what it means, how to test, tips and tricks, and all that fun stuff.  Here are just a few options to look at

https://mobiforge.com/news-comment/standards-and-browser-compatibility

https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing

https://dzone.com/articles/fixing-javascript-cross-browser-compatibility-issu

https://www.microfocus.com/media/white-paper/cross_browser_functional_testing_best_practices_wp.pdf

---

---

In this first post I want to specifically focus on Compatibility View in IE: what it means, how it works, and how it can be set.

From Wikipedia: Internet Explorer 8 was promoted by Microsoft as having stricter adherence to W3C described web standards than Internet Explorer 7. As a result, as in every IE version before it, some percentage of web pages coded to the behavior of the older versions would break in IE8 […] To avoid this situation, IE8 implemented a form of version targeting whereby a page could be authored to a specific version of a browser using the X-UA-Compatible declaration either as a meta element or in the HTTP headers

IE 8? Wait, exactly how long ago was that? What the heck, why is this still an issue today? Shouldn’t all websites have been updated by now to no longer need these “quirks” or “hacks” that were needed prior to IE8? Well, that is a slightly rhetorical question. Secondly, IE8 and even IE9 required their own set of “hacks” to make sites render the same as in other browsers.

How does it work? The simplest answer is that the browser will “emulate” the behavior of the older version, so that the assumptions the page made about the browser’s behavior would still be valid. Notice that I say “emulate” instead of “reproduce”. This is because the compatibility mode in the browser is not using the exact rendering engines used in the original version. When testing it is best to use VMs with the actual software version installed to ensure you are seeing the proper rendering of the page (see https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/samples/dn255001(v=vs.85))

Most people reading this post should be fairly familiar with the ability to set Compatibility mode within the browser itself. This can be done using the following methods (based on version).

• All versions up to IE11

 

• • In the address bar, at the far-right side, there is an icon that looks like a broken page. By clicking on this icon the website is added to a local list of exceptions called the “Compatibility View list
  • This list can be viewed/managed from the Compatibility View Settings dialog
  • On this dialog you can also select to include updated lists from Microsoft
  • Or, display Intranet sites in Compatibility View
  • Or, display all sites in Compatibility View

• IE9
  • Access the menu via the Gear icon and select F12 Developer Tools
  • Or press F12 on your keyboard
  • In the bottom window of your web browser a new row will appear starting with “File”
  • Click on Browser Mode and change it to IE9
  • Click on Document Mode and change it to IE9 standards

• IE10
  • Press the ALT key to bring up the top menu and then go to Tools > Developer Tools
  • Or press F12 on your keyboard
  • In the bottom window of your web browser a new row will appear starting with “File”
  • Click on Browser Mode and change it to IE10 (NOT the IE 10 Compatibility View)
  • Click on Document Mode and change it to IE10 standards

• IE11
  • Press the ALT key to bring up the top menu and then go to Tools > Developer Tools
  • Or press F12 on your keyboard
  • In the bottom window of your web browser a new section
  • Scroll down to locate the Emulation mode (icon with desktop screen and mobile screen)
  • Set document mode to Edge (Default)
  • Set User agent string to Default

 

 

 

Note, IE will open ALL Intranet sites in Compatibility Mode by default

Besides using the tools within the browser this mode can also able to be controlled via a few other methods – and depending on where the mode is set can make a huge difference

The first method of setting compatibility mode can be managed at the website level by one of the following:

• Set <!DOCTYPE> at top of HTML file (see https://alistapart.com/article/doctype)
  • While this does not affect the Compatibility Mode of IE as such, based on whether this element is included or not does factor into the browser’s calculations when determining how to render
• Add a meta tag like “<meta http-equiv=“X-UA-Compatible” content=“IE=7” />” within the header section of the html document
• Or by specifying “X-UA-Compatible: IE=7” within the HTTP headers that is sent with each page
• You can also specify multiple modes and the highest known mode will be used
  • <meta http-equiv=“X-UA-Compatible” content=“IE=7; IE=8” />
  • OR (to use current highest) <meta http-equiv=“X-UA-Compatible” content=“IE=edge” />
• You can see more at: https://msdn.microsoft.com/en-us/library/ff955275(v=vs.85).aspx

Other ways to set the Compatibility Mode:

• Microsoft keeps a list of known websites that need to run in Compatibility Mode
• Internet Explorer Enterprise Mode, which allows an organization to maintain a list of specific URLs that they want to be rendered in Compatibility Mode, using a tool from Microsoft called “Enterprise Mode Site List Manager”
• Via Group policy settings (applied at the organization level)
  • Basically, a GPO can be added within Active Directory to set Registry setting which controls the local machine’s Compatibility View Sites list for all sites, or for specific sites
• More info: https://msdn.microsoft.com/en-us/library/ff406036(v=vs.85).aspx

 

Now here comes the fun part. And something that bothered me to no end until we were finally able to get this all straightened out. What is the order of precedence for all these diverse ways to set Compatibility Mode? Why is this a problem?

Well, see the hierarchy below. We knew there was an issue, somehow, with compatibility. Because the script errors were specific to IE7 and IE8. The first thing we tried was to use the X-UA-Compatible setting in the HTTP header. This did resolve the issue for one client. And only one.

Why not others? Two reasons – one was using the Enterprise Mode Site List, and the other was using Group Policy. As can be seen from the list below, our directive to the browser on the mode to render the website in was being overridden on the customer side

Here is the general order

1. <!DOCTYPE>
2. X-UA-Compatible setting (Meta tag takes precedence over http header when both are present)
3. Compatibility Site lists
   1. Local Compatibility Site list
   2. Microsoft Compatibility Site list
   3. Enterprise Mode Compatibility list
4. Developer Tools emulation setting (only active for lifetime of the tab)
5. Group Policy settings trump all

 

Now the question I am sure you are all asking is, how did we resolve this issue for our clients? Ha. Ha, I say. It would have been “nice”, or at least, easier for developers, to just tell our customers to change their network policies. But that isn’t a very good message to send to our clients. Or our vendor partners.

Unfortunately, this had to be resolved in two different ways. One, is, well, exactly what I said above. We provided clear communication that if they add our website to a compatibility mode list that specifically directs the browser to use IE7 mode, then that website it not going to function as expected.

The other solution… tune in for the next article in this series 😉