The Perils of User-Agent Sniffing, 2011 Edition

I continue to be amazed at how often site-compatibility issues turn out to have a root cause related to User-Agent sniffing.

For instance, earlier this year, someone wrote into the comments section on one of my posts noting that the HTML5 canvas art site WeaveSilk.com wasn’t working in IE9. After reading through thousands of lines of JavaScript, including various libraries, I found the culprit at the very end of the page, which you can see here, along with the very simple fix:

Simply put, if the browser’s UA string contained “MSIE”, the site skipped all of its initialization code. Oops.

Today, I encountered two more issues of this class of problem. One is with the Google Fonts site. By default, if you load this site, you’ll find that it’s blank and contains no content:

A quick peek in Fiddler shows that the problem is that the server is returning HTML pages with an “Your browser is unsupported” message when IE attempts to download the CSS and JS for the page.

If you use the F12 Developer Tools or Fiddler to change the User-Agent string, then the site returns correct content and the page loads correctly:

Because the Google.com domain is on the Compatibility View list, the site is in IE8 Browser Mode by default. You can see this on a Google page by pressing F12 to see the Developer tools; the Browser Mode is IE8: . While the page itself can select a later Document Mode using an X-UA-Compatible meta tag, the User-Agent string is selected by the Browser Mode, not the Document Mode. The distinction between these two modes is often misunderstood—there’s a great MSDN Article which explains the difference between the Browser Mode and Document Mode settings.

The second UA-string issue I encountered today was closer to home. Eagle-eyed viewers of the high-resolution video included in the blog post announcing the IE10 Platform Preview 2 might have observed that the text in the Fireflies demo page claims that the Platform Preview is “Internet Explorer 7” while the status bar clearly indicates that it’s an IE10 Platform Preview build running in IE10 document mode:

If you look at the source of the demo site, you’ll notice that FeatureDetection.js includes the following code (typos and all):

The code isn’t looking for the Trident/6.0 token sent in the IE10 User-Agent string and hence doesn’t realize that this PPB has loaded the site with Browser Mode:  Internet Explorer 10 Compatibility View. The page itself is running in IE10 Document Mode because it includes the following META tag:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

Because the page is properly running in IE10 Document Mode, the markup (including the CANVAS element) continues to work correctly, but the “What browser are you using” notice at the bottom left is misleading.

You might be wondering why the video indicates that the page was loaded in Browser Mode: IE10 Compatibility View. The answer is simple-- when the video was recorded, the new Fireflies demo hadn't yet been published. We were using the PPB to load a mirror copy of the demo from an internal staging server on our Intranet. By default, Internet Explorer runs Intranet pages in Compatibility View.

Now, when you visit the IETestDrive site, you should see a proper browser identifier because the browser will be in IE10 Browser Mode:

-Eric