“Browser sniffing”: a cautionary tale

Recently it was brought to our attention that certain pages on our site were looking a little funny in IE11.

ie11-screenshot-checkout-before ie11-screenshot-more-before

How it looked

ie11-screenshot-checkout-afterie11-screenshot-more-after

How it should have looked

The checkout button was taller than it should be, and the links were floating next to each other.

This was a major surprise to say the least. Microsoft has produced a pretty good standards-compliant browser since IE9, and it handles the basics of modern CSS layout fairly well. Generally, if a page looks as it should in Firefox or Chrome, then you would not expect any issues when looking at it in IE9+. When IE11 came out late last year, no one thought it necessary to do regression testing on the site – there was nothing experimental, or edgy that was used in the site that we would expect to fail.

As you can see in the examples above, the desired layout and styles are fairly straightforward and run-of-the-mill. Why was IE11 having a problem?

Looking at the links example, the usual problem with this sort of skewed layout is uncleared or uncontained floats – the next element simply slots in where it can in the layout. But it’s a simple list! Why would anything be floating?

The first step in any front-end troubleshooting is a web inspector. Firebug for Firefox led the way in what could be done in this area (and, in all seriousness, the history of web development could be broken into two periods: before and after Firebug!), and all modern browsers now come with a fairly robust web inspector by default. So I fired up VirtualBox to run IE11 in Windows 8.1 and had a look.

The HTML in the links area is as follows:

<div class="item-list">
<ul>
<li class="first">
<a title="Standard Post" href="/home/sending-within-nz/letters-documents/standard-post">Standard Post</a>
</li>
<li class="last">
<a title="FastPost" href="/home/sending-within-nz/letters-documents/fastpost">FastPost</a>
</li>
</ul>
</div>
<span class="section-grid-read-more">
<a title="Letters &amp; documents..." href="/sending-within-nz/letters-documents">More...</a>
</span>

Then I inspected the list items in the list of links, and found something interesting. This CSS was applied:

.oldgecko #grid-section li {
    float: left;
}

What? “oldgecko”?

Finding it in the CSS there’s the following note:

/*OLD GECKO (Firefox 2 and its ilk) ########################################*/

That makes sense, I guess, Firefox 2 was “oldgecko”. And since its market share is pretty much non existent now, there seemed to be no good reason to keep this CSS around if it was breaking other things, so the fix was easy enough – delete the offending code. But how did it happen that a fix intended for Firefox 2 ended up affecting IE11? Lots of years separate the two browsers. They use different rendering engines.

The class itself was added to the HTML element from this line in our global JS file:

/* We need a CSS hook for older gecko browsers such as Firefox 2 */
if($.browser.mozilla &! Array.reduce) { $('html').addClass('oldgecko'); }

$.browser is a jQuery check of the browser’s user agent string. It was deprecated by jQuery version 1.3, which the non-responsive parts of our site still use (it was removed completely in version 1.9 – the responsive parts of our site use 1.10 at the moment). But it’s checking for “mozilla”, not IE!

IE11 changed its user agent string from previous versions of IE:

IE10 (Win7) Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
IE11 (Win8.1) Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

So, apart from adding “like Gecko”, the string no longer has “MSIE”. This has caused $.browser.mozilla to return true!

Now, it’s easy to point the finger and laugh at whoever did this. “Browser sniffing” is not considered good practice and every mention of it invariably comes with a “you shouldn’t do this” disclaimer. But there are few developers out there who have never done it. I know I have (and to test for Firefox 2 as well, although with a slightly different test). Sometimes, with deadlines looming and available hours to work on a project running out, shortcuts such as these look very appealing. Sometimes there is no obvious workaround. But if you’re looking for an example of why it’s wrong and how it can come back to bite you, then here’s one right here.

Brian Milne
Front-end Web Developer

This entry was posted in Uncategorized and tagged . Bookmark the permalink.