Mozilla

Firefox goes 2-digit, time to check your UA sniffing scripts

We all know it: UA-based browser detection is bad, the right way is feature-detection. Regardless, legacy code relies upon UA sniffing and may need to be updated for Firefox 10’s release.

Even if it looks simple, UA parsing has proven to be a headache for numerous script authors. Though the structure of an UA is defined in the HTTP specification, the way relevant information is conveyed varies from one vendor to another. Also, the information you want to extract from it is not always the same: sometimes you want to know the browser (Firefox, SeaMonkey, Safari, Chrome, IE, Opera…), but most of the time you want to know the engine that powers them (Gecko, Webkit, Trident,…). You also need to get the version of the browser or the engine.

Old scripts often made some undue assumptions. Some are assuming that browser version numbers will never reach 10… This is not the case: Opera and Chrome have already crossed this landmark long ago, Firefox will reach it next week and IE soon after.

A few examples of Firefox UAs that your scripts should allow:

  • Regular Firefox version: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0
  • Nightly and Aurora Firefox versions: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0a1) Gecko/20120122 Firefox/12.0a1
  • Chemspill Firefox version (three numbers) Mozilla/5.0 (Windows NT 6.2; rv:10.0.1) Gecko/20100101 Firefox/10.0.1

So, it is the last moment to check your UA-based browser detection code before your site goes havoc!

Last chance to check

Do it right now, in two weeks it would be too late.

What to do?

  1. Code inspection: check your code to see if there is some UA-based browser detection code. If so, check if it handles multi-digit versions. (At the same time you could check if it is useful at all. Some old UA-detection code has not worked in ages, or try to go around problems fixed since years in browser…)
  2. Library inspection: lots of libraries perform UA-based browser detection. If you are using any of them, check if it still is working with a version of Firefox with 2 digits. If not, notify the author of the lib and open a bug on bugzilla so that we can help others as all their customers are likely to suffer from the same problem.
  3. Check if your site is working with the next Firefox version: download the Beta release of Firefox 10 (you can run several versions of Firefox simultaneously) It is always a good idea to use the beta, or even the aurora, version of Firefox if you are maintaining a site: you’ll discover incompatibilities earlier and will get time to fix them before your users start complaining. We are doing our best to prevent problems, but sometimes old code rely on incorrect behavior and stop working even when we are only fixing bugs.
  4. Test other sites :-). Use the beta or aurora version of Firefox and surf the web. When you hit a UA-related problem report it with bugzilla. Give us as much info as possible like the importance of the site in your country and if you have conducted any action yourself. That way our evangelism team will be able to prioritize work adequately.

Finally, you should plan to get rid of these UA-based browser detection mechanism. If you can’t — and I know it isn’t always possible — I would be glad to know why: so please let us know in the comments below.

Now it is time to check your sites :-)

Thank you very much for your help.

41 comments

Comments are now closed.

  1. David Mulder wrote on January 23rd, 2012 at 02:12:

    I remember using some browser detection + os detection to style certain input elements consequently (one of which was the file upload field). Secondly I also used it to account for a 1px difference in font-size on different browsers (not sure about the details anymore, so I don’t know whether that was a browser issue or a (google web)font issue). Either way, both issues that couldn’t be detected directly. Oh and, I also used this kind of detection to block a mobile web-app from non-mobile devices.

  2. Mathias Bynens wrote on January 23rd, 2012 at 03:11:

    It would probably be useful to include an example double-digit UA string in this blog post.

    1. Jean-Yves Perrier wrote on January 23rd, 2012 at 04:56:

      You are right. I have added a few typical 2-digit Firefox UAs.

  3. Benno wrote on January 23rd, 2012 at 04:44:

    This would also be a good occasion for removing any build date dependencies since now that it has been frozen for quite some time to 20100101 for stable versions and might get removed in the future.
    https://bugzilla.mozilla.org/show_bug.cgi?id=572661
    https://bugzilla.mozilla.org/show_bug.cgi?id=660498

    1. Jean-Yves Perrier wrote on February 14th, 2012 at 05:01:

      This won’t be done at the same time. But it will happen in the next Firefox for Mobile release. On desktop, it may happen after that, or before, or not.

  4. Aryeh Gregor wrote on January 23rd, 2012 at 16:52:

    Here’s a case where MediaWiki UA-sniffs for Gecko:

    http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?revision=108550&view=markup#l495

    The comment explains it pretty well. In theory it should be possible to test for it by creating an iframe and sticking it in the page and navigating it to a fragment before it’s finished loading and seeing if it jumps, but realistically, it’s not practical. So UA sniffing is used instead.

  5. Mogden wrote on January 25th, 2012 at 13:12:

    UA version sniffing is indispensable when working around browser bugs. For example, Chrome Windows < 18 has horrible problems playing lots of HTML5 audio. It'll crash at some unpredictable time. How could we detect that, in order to reduce the use of sounds in our app, in a nice way?

  6. Tai Travis wrote on January 25th, 2012 at 21:05:

    The Modernizer js library is a great solution to this problem. You can configure a custom download so you only need to test for the features you need.

  7. Leisha Fleming wrote on January 31st, 2012 at 11:17:

    Pardon me techno folks,

    I am just a simple girl with a basic question. Last time I update MF to 9.0.1, my email account thru ATT/Yahoo went crazy on me. I had to constantly log in even though “keep me logged in” was checked. Of course they said it was an MF problem. It apparently changed something. What is this update bound to do to my computer??? Should I update ever again? I am scared….

    1. Probably wrote on February 1st, 2012 at 03:52:

      I’ve searched bugzilla for this.
      https://encrypted.google.com/search?hl=nl&q=site%3Ahttps%3A%2F%2Fbugzilla.mozilla.org%2F+att+email+firefox+9.0.1&oq=site%3Ahttps%3A%2F%2Fbugzilla.mozilla.org%2F+att+email+firefox+9.0.1&aq=f&aqi=&aql=&gs_sm=e&gs_upl=35383l38347l0l39269l10l10l0l9l0l0l39l39l1l1l0

      The bug that comes up is this one: https://bugzilla.mozilla.org/show_bug.cgi?id=713014

      According to the information there, the problem should be fixed when you update to Firefox 10.
      So yes, I definitely recommend you to update. Another reason to do so is because outdated software poses a great security risk. I’d be wise if you checked the rest of your software (https://secunia.com/vulnerability_scanning/online/) or at least your plugins (https://www.mozilla.org/en-US/plugincheck/).

      Hope this helps!

    2. David W, Smith wrote on February 2nd, 2012 at 15:22:

      I still have Fire Fox 4 so I could keep my yahoo and google toolbars. If I was anable to have those, than I went to my downloasds under tools. I had to scrool down pertty far to find the old Fire Fox 4 download and I redowloaded it so my yahoo anf google tool bars came back. Others say nothing works very well by keeping an old version of Fire Fox on my computer, So I can just say this as for your problem(s) Just go back and use what worked for you before. You WILL however keep getting pop ups at random to update to the newer FireFox. I just click on the red X to make it go away. So I would just suggest you go back to what works for you and if this is a wide spread problem than others will get the message to them and you can later see if they have ever fixed the problem. I have been looking for anything that may say they fixed the tool bar problem, So I will just keep using Fire Fox 4. It works for me . Just copy and paste this http://download.mozilla.org/?product=firefox-4.0&os=win&lang=en-US This will work for you as it dose for me

      1. Jean-Yves Perrier wrote on March 1st, 2012 at 00:42:

        I wouldn’t use Firefox 4 to surf the net today. It is extremely bad advice to recommend using a non-maintained version.

        It has security bugs that are actively exploited in the wild.

    3. Robert Schwedt wrote on February 29th, 2012 at 13:47:

      Also you will find problems with Yahoo news comments they never load right i also have some Facebook problems with FF not wanting to load the page if it opens a new tab

      1. Jean-Yves Perrier wrote on March 1st, 2012 at 00:45:

        When facing problems with Firefox, the best move is to go to SUMO ( http://support.mozilla.org ). There, people with the required expertise can help you.

        Anyway I hint you to try to start Firefox in safe-mode, disabling temporarily its extension: Facebook problems are unlikely to get unnoticed before a release as so many people are using the site, so it may be one extension causing havoc. Anyway it will be the first action required to you by the SUMO people.

  8. Nick Gilbert wrote on January 31st, 2012 at 13:31:

    Seriously, has this ever actually happened?! Nobody would store version number in a 1 digit char field. They’re more likely to store it as a string or an int..

    1. Brent Tilley wrote on January 31st, 2012 at 13:48:

      My immediate thought to this article’s title was that people have used a function similar to that of PHP’s strpos() and checking for a “1” after extracting the version number. This of course would return true for a browser with a version of 10, 11, 12, etc.

    2. Yehuda wrote on January 31st, 2012 at 14:53:

      @Nick
      Storing the version number as a string could lead to a problem in version detection. In JS, if you test “10.0” >= “3.6”, you’ll get the Boolean false, because this is a string comparison, not a numerical comparison.

    3. Simon wrote on January 31st, 2012 at 15:19:

      It’s not a matter of storing it in a 1-digit field – it’s a matter of what they’re looking for. Our web-based app blacklists older browsers that we know don’t work, and it did so by looking for the string “Firefox/1″ in the user agent. And that, of course, matches “Firefox/10″, causing the new version to be blocked.

      Easily fixed, of course – I’ve changed it to specifically look for a dot after the one, which still matches the older user-agents, but not FF10. But it *did* need fixing.

      1. Nick Gilbert wrote on January 31st, 2012 at 15:48:

        OK I see the problem. Personally though, I would never write code which treats numbers like a string as it’s a stupid idea for obvious reasons and I be tempted to sack anyone who put those kinds of hacks near my code… :)

      2. Nick Gilbert wrote on January 31st, 2012 at 15:52:

        …especially as it’s so obvious that that code can’t work. It’s about as stupid as checking to see if the browser is firefox by seeing if the string “Fire” is anywhere in the user agent string. It might work for a bit, but when a browser called Fireblaze comes out, you’re screwed.

        1. Brent Tilley wrote on January 31st, 2012 at 16:03:

          Not to mention the user agent string can be spoofed to be just about anything.

        2. Simon wrote on January 31st, 2012 at 19:11:

          Eh, it worked for what it was intended for, which was to detect people running an unsupported browser, and redirect them to a page telling them so.

          It’s an enterprise app, so supporting every browser under the sun isn’t an objective – it just needs to recognize Firefox and IE, and distinguish between supported vs unsupported versions of both. And if they work around it by spoofing the user agent, no big deal – it just means there’s no point in them reporting problems, because “which part of ‘unsupported’ did you not understand?”.

          1. ZiggyTheHamster wrote on February 13th, 2012 at 14:35:

            Enterprise app or not, excluding “unsupported” browsers because they’re not Firefox or IE is not a good practice. Iceweasel is Firefox-compatible, but can’t access your app because it’s not supported.

  9. fgsfgsg wrote on February 3rd, 2012 at 08:20:

    Google Orkut – social network popular in Brazil – see Firefox 10 like version 1.

    So far, done nothing to solve.

    1. Jean-Yves Perrier wrote on February 10th, 2012 at 11:00:

      Google was contacted on January 23rd. See https://bugzilla.mozilla.org/show_bug.cgi?id=720179 .

      1. Jean-Yves Perrier wrote on February 10th, 2012 at 22:54:

        And both Orkut.com and Orkut.com.br were finally fixed during the European night!

        :-)

  10. Alhadis wrote on February 7th, 2012 at 01:11:

    I tend to avoid UA sniffing when possible, but one frequent use I have is checking for the presence of CSS3 gradient support server-side. I wrote a PHP function that checks if a user’s browser appears capable of rendering CSS3 gradients; and if not, it outputs a stylesheet link that loads background-images into the DOM.

    Now, I could have always included the background-images *before* the lines that declare the linear or radial gradients, but I noticed WebKit still sends out a HTTP request to the URI (whereas Firefox doesn’t). In the interests of optimising server demand as much as possible, I decided to only have those background-images loaded for browsers that appeared in capable of rendering gradients.

    So far, it’s worked a treat. Worst that could happen is a solid colour showing up in the background anyway. But this is one example of how UA sniffing can be used for something fairly minor and cosmetic.

  11. mei wrote on February 8th, 2012 at 11:02:

    I am not a computer tech wiz…all I know is after updating Firefox on my Mac running OS 10.5.8, I have great difficulty if at all, getting on the internet…great inconvenience and I need to know how to fix if possible…may I have the dummy version of how to?

    1. Jean-Yves Perrier wrote on February 10th, 2012 at 10:57:

      Mei, this is unrelated to the 2-digit problem, as only a couple of sites may display a pop-up or similar. I urge you to reach a support site like http://support.mozilla.org

      They would be able to help you diagnose the problem.

  12. Herbert Peters wrote on February 10th, 2012 at 21:46:

    FF 10.0 was fine. FF 10.0.1 caught one of our sites out. The version was incorrectly truncated to 0.1 instead of 10.0

  13. Chas4 wrote on February 11th, 2012 at 10:08:

    This hit Opera over 3 years ago

    10 is the one
    http://my.opera.com/hallvors/blog/2008/12/19/10-is-the-one

    1. Jean-Yves Perrier wrote on February 14th, 2012 at 05:07:

      Opera 10 wasn’t released with the UA described in the article you linked. They kept the version number to Opera/9.80 and added Version/10.00 (which is the new version number).

      See: http://dev.opera.com/articles/view/opera-ua-string-changes/

  14. Phil Pishioneri wrote on February 13th, 2012 at 17:08:

    Ironically, the ‘Articles by Category’ on the right-side of this web page lists “Firefox 10″ before “Firefox 3.5″.

    1. Chris Heilmann wrote on February 15th, 2012 at 04:07:

      hah! the perils of sort vs natsort :) well spotted.

  15. anggel wrote on February 14th, 2012 at 04:55:

    http://my opera.com/hallvors/blog/2008/19/10-is-the-one

  16. Pete wrote on February 14th, 2012 at 11:55:

    My concern, it that Kaspersky Virtual Keyboard works as well as Duckduckgo.
    I have had to uninstall the Mozilla/Firefox upgrades and reinstall an older version that is compatible. Is this new upgrade compatible?

    1. Jean-Yves Perrier wrote on March 1st, 2012 at 00:47:

      The question is reverse: it is Kaspersky Virtual Keyboard that must be compatible. Have you asked Kaspersky support.

      As of Duckduckgo, it works like a charm and I never had a problem with it in any version of Firefox.

  17. Zafar Al Masood wrote on February 18th, 2012 at 02:12:

    When in some text field, I input with barcode-scanner, A download windows appears in Firefox browser. Although a barcode-scanner act like a keyboard input device, it must not show download window. I blocked download option in firefox browser (Tools->Options->General Tab-> Unchecked download options) nothing happens, even I disable java-script. Till download windows appears in Firefox browser with barcode-scanner input.

    IE(any version) not showing this. What can I do? Can anyone help me. I am developing an ERP system which is browser dependent. I installed latest Firefox.. Till Goom ma gooma.. ahaaa..

    1. Jean-Yves Perrier wrote on February 18th, 2012 at 02:16:

      This blog is not practical as a support forum (especially on a problem not related to the subject of the article). You should explain your problem on http://support.mozilla.org where people will help you diagnose the problem and eventually fill a bug report. Anyway starting in safe-mode to see if the problem is still there will be the first test to conduct.

  18. joe wrote on February 22nd, 2012 at 11:41:

    Oh my, what a hoot! Sad that so many scripters wrote poor code. Anyone ever heard of regex? /d+(.d+)?/ That wasn’t so hard was it and you can do it in JS, Java, PHP, ASP… anywhere. Simply put, this is just a case of amateur, poorly thought out code not unsurprisingly failing.

    1. Jean-Yves Perrier wrote on March 1st, 2012 at 00:52:

      Writing UA detection that work in all cases is far from easy.

      Note that your regexp will match more than only the Firefox/Gecko version number in any UA string. There are other numbers in the UA then the version. Especially there are dates that will match your regexp each time.

Comments are closed for this article.