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.
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.
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.
Brilliant! That last item is exactly what I’m seeing, and so I brought up the Compatibility View settings (click on the sprocket icon in the IE toolbar, and it’s the option near the bottom. That brings up the following dialog, which shows the checkbox in question:
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.
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.
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.