Works on My Machine…or Does It?

It’s always frustrating when you’re working on a project, and everything looks good when you’re running it from Visual Studio, and then you deploy to your web server, and suddenly something’s not rendering correctly. In this post, I’ll give you some tips for troubleshooting these problems when the target browser is Internet Explorer.

The Project

I’m working on a project that uses ASP.NET MVC 5 and leverages the out-of-the box support for the Bootstrap UI framework.

Having completed the initial phase of development, and wanting to provide a copy of the app for the client to test on their own network, I arranged to have all the necessary stuff set up (DB, web server, etc.), and dutifully published the bits to the web server location. So far, so good.

The Problem

When I went to run the application, I discovered a strange UI issue, where the div on the page that contains the page title (in the default template, it’s the one that uses the “jumbotron” class, was riding up underneath the navigation bar, and the navigation bar was taller than normal, which resulted in the text inside the div being partially cut off:

This isn’t the first time I’ve seen the issue, as I’d run into it when testing on local IIS instead of the default of IIS Express. So when I saw it again, I decided to open up the Internet Explorer F12 developer tools (I’m running IE 11 on Windows 8.1, Update 1), and see what I could find. I used the Select Element button in the DOM Explorer tab to examine the div that was riding up, and discovered in the Console that the browser was using document mode 7 (rendering as if running IE7), as shown below (click for larger image):

Since I wasn’t sure what was causing this, I flipped over to the Emulation tab to investigate. Helpfully, the Document Mode selector indicated that the document mode was defaulting to 7 “Via intranet compatibility settings,” the text of which includes a link to MSDN documentation on the Emulator tab:

Those docs included this helpful bit of info:

New in Windows 8.1 Update, when the Document mode has been changed from the default, you’ll be shown a reason why. Here’s a quick list of the reasons with explanations:

• Via F12 developer toolbar: You have changed the Document mode using the Document mode drop-down list.
  • Via X-UA-compatible meta tag: The webpage developer used a meta tag to specify a legacy document mode.
    • Via X-UA-compatible HTTP header: The web server has requested a legacy document mode via an HTTP header.
      • Via local compatibility view settings: The site was manually added to the Compatibility View settings.

        • Via the compatibility view list: The site is on Microsoft’s Compatibility View list.

          • Via intranet compatibility settings: The “Display intranet sites in Compatibility View” box is checked in the Compatibility View settings.

If you’re wondering why it renders properly in IIS Express, but not in IIS, that’s because it’s hitting the “localhost” URL, so Internet Explorer does not treat it as an intranet site. By contrast, when I was viewing the site in IIS, I was doing so by the server name, so the Compatibility View defaults for intranet sites kicked in.

Back to the F12 developer tools, the document mode selector also included a link (the “i” icon) to this helpful article on modern.ie that explains the document modes and how developers and administrators can override the default behavior.

The Solution

Now, if I want to test and make sure that this is truly the issue, I can just uncheck the checkbox, and close the Compatibility View dialog, and voila! The site now renders as expected:

But that’s not a practical solution for end-users. If I had the ability to set group policy for my users, I could use GP to tell IE not to render this site in compatibility view, but most developers don’t have that as an option.

Another option is to use the x-ua-compatible META tag to specify the desired mode, like so:

<meta http-equiv="x-ua-compatible" content="IE=9">

Since the project I’m working on targets IE8, I could use IE=8 as the value. But it turns out that as long as the tag is present and has a valid value, the page won’t default to compatibility view. I ended up setting the value to IE=11 (you could also use IE=Edge to always target the latest version, but that didn’t work for my needs since I needed to target IE8), which clears up the rendering issues without limiting newer versions of the browser to the feature set supported by IE8. IE8 users won’t get fancy CSS animations and such, but once the organization is able to migrate to a newer browser version, no change will be needed to the meta tag for them to take advantage of such features.

Note that you can also specify the compatibility mode using a custom HTTP header, which comes in handy if you want to enforce a specific mode at the server or site level, without having to modify all of the pages and/or layouts in a given site.

More on the Problem

After doing some more spelunking, it turns out that at least part of the problem I was running into with the rendering was coming from the fact that I started the project with an Empty ASP.NET project template, and added the features I wanted, including Bootstrap, etc. As a result, my project didn’t have the Site.css that is included in the default MVC 5 template, and one of the style rules it adds is a padding-top value of 50 pixels. That rule pushes the body content below the navigation bar, so it doesn’t ride up under, as I was seeing. I still haven’t figured out quite why the navigation bar gets taller under an IE7 document mode, but I’ve got things working well for the target browser, so I probably won’t spend more time troubleshooting something that’s no longer an issue, even though there’s a part of me that wants to figure it out.

Conclusion

When things go wrong in rendering your site, it can be very frustrating, particularly when a site that was working in IIS Express suddenly stops working when you test it in full IIS.

Fortunately, the IE Developer Tools keep getting better with every generation, and for this issue in particular, the Emulation tab turned out to be a lifesaver, giving me the info I needed to locate and correct the problem, along with links to documentation to better understand the underlying settings. So the next time you run into an issue, just hit F12, and see what you can find!

Did you find this post useful? Please pass it along to friends and colleagues! And I welcome your comments and experiences in the comments section below.

Comments

Comment by Garth Vander Houwen on 2014-05-27 22:07:00 +0000

If you are not required to support IE8 the http header with a value of “EDGE” is the only thing I have found to work reliably. The meta tag works until anything above it in the the page is not perfect HTML5 (the conditional IE comments in the HTML5 boilerplate for example) , and then quirks mode can kick in.

Comment by devhammer on 2014-05-28 09:11:00 +0000

Garth, thanks for sharing that info.

I agree that if you don’t need to support IE8, EDGE is the way to go.

Definitely, any time you have invalid markup, you run the risk of getting dropped into Quirks mode. While I haven’t tested that specific scenario, I’m betting that the Emulation tab would probably still help track down the cause of the issue.

Thanks for reading!

Comment by Martyn (FrankCode) on 2014-07-01 17:17:00 +0000

Nice post. The IE compatibility view can behave really strangely, even more so if you have users with CV on and then you force it off using meta tag. I have suffered with and blogged about these issues in the past if you are interest http://frankcode.wordpress.com/2013/10/17/a-guide-to-ie-compatibility-view-and-x-ua-compatible/

Comment by devhammer on 2014-07-02 11:08:00 +0000

Thanks, Martyn. Your post looks like a good resource. Thanks for sharing it.

Comment by Jeff on 2014-08-21 16:56:00 +0000

This just saved me a ton of time figuring out what was causing this issue. Thanks for the awesome and detailed post!

Comment by devhammer on 2014-08-22 11:14:00 +0000

My pleasure. Glad to hear it helped, thanks for letting me know!

Comment by jmarquis75 on 2014-11-06 06:42:00 +0000

GENIUS!!! I have lost so much time trying to figure out why my jquery mobile styling wasnt showing up or simple css rounded edges…. THANK YOU!!

Comment by lgibson76 on 2015-03-03 20:47:00 +0000

awesome! put in the meta tag and worked like a charm. thanks for having this info out there

Comment by devhammer on 2015-03-03 21:23:00 +0000

Very glad it worked for you!

Comment by Eric Eskildsen on 2015-07-10 11:49:17 +0000

Perfect! Thanks for the very interesting and helpful post!

Comment by G. Andrew on 2015-07-10 12:03:27 +0000

My pleasure. Glad you found it useful!

Comment by swathi on 2015-07-14 07:30:27 +0000

Thank you so much!
This post is such a life-saver!

Comment by Guillermo Munoz on 2015-09-01 16:54:14 +0000

Thank you. I was having this very problem, and after some searching and reading other things that were less than helpful, I saw your article, and it explained exactly what was happening – and did so very well. Excellent job.

Comment by Tfreez on 2015-09-24 11:36:33 +0000

Genius!!..thanks for sharing your solution G. Andrew. I was going nuts trying to figure out this same problem with my MVC app

Comment by G. Andrew on 2015-09-24 11:58:00 +0000

Glad it helped. Thanks for letting me know.

Comment by Omar C. on 2020-04-13 17:08:12 +0000

Saved me time in a rapid web app request. – Thank you!!