Final User Agent String for Firefox 4

With a title like that, you just know this is going to be fun. (No, seriously.)

The user agent string is one of those wonderfully eclectic things, a balance of modernity and antiquity. Except mostly skewed toward antiquity. It’s grown, piece by piece, over the years; because everyone has their own special way of parsing it, it’s a notoriously sensitive beast. Adding to it is relatively simple, but removing or rearranging bits is not.

If you’re a web developer and you rely on bits in the UA string, this post is definitely for you. As it so happens, the UA string for Internet Explorer 9 has undergone some revision, and Microsoft has recently announced the string for IE Mobile. This makes the time ripe for a revision so that web developers can make the necessary changes to sniffer code all at once.

This is what the User Agent string will look like for Firefox 4 on 32-bit Windows:

User Agent string

Note that this string will change depending on the user environment, platform and architecture. It’s particularly important to understand that the string can change quite a bit depending on if you’re on a phone, on Windows, Windows 64 bit, a Mac or any variety of Linux-based devices.

In addition, Gecko, the underlying browser platform used by Firefox, is used as a basis for a number of other products. Those products will likely produce Firefox-like strings, and you should be prepared to handle them and treat them much like Firefox. (See below for more details.) If you’re sniffing the UA string, you should consider carefully what you’re trying to achieve, and whether you can feature-sniff instead. See this excellent article for some suggestions on how you can do this.

For a complete reference, see the Gecko User Agent String Reference. There’s also a text file you can test against, with a large set of UA strings for new and old versions of Firefox and other Gecko-based browsers.

Here’s a list of what’s changed since Firefox 3.6:

1) The locale (e.g. “en-US;”) is gone. The locale of the browser is not always the same as the locale the user prefers to view content in — the HTTP Accept header is the recommended source of this information.

2) The “U;” is gone. Back in the day, this was used to denote browsers with strong encryption from those without. Nowadays, no browser ships with weak encryption. This means that if you’re sniffing for “U;”, you should stop doing so, or — if you must — sniff for the lack of strong encryption (“I;” or “N;”).

3) The “Windows;” prefix is gone from the (surprise!) Windows-specific string. Note that the number of semicolon-delimited fields within the platform token varies between different platforms!

4) Browsers running on the Nokia mobile Maemo (and Meego) platforms will now report themselves as “(Maemo; Linux armv7l; …)”. This is in keeping with the Android mobile string “(Android; Linux armv7l; …)”, and we will continue to add different strings here as more Linux platforms come into play.

5) A rather minor detail, but worth noting — for Linux i686 builds running on an x86_64 platform, the platform-specific part will now read “(X11; Linux i686 on x86_64; rv:…)”. This changed from “(X11; Linux i686 (x86_64); rv:…)”. (Nested parentheses are a bad idea!)

6) The Gecko build date in the “Gecko/yyyymmdd” token has been frozen to 20100101 for Firefox releases. This means:

If you want to detect whether the browser is genuine Gecko, search for the strings “Gecko” and “rv:”. The presence of these two strings will distinguish Gecko from browsers who state they are “like Gecko” in the UA string.
If you want to determine the Gecko version, first — as noted above — consider carefully whether you can feature-sniff instead. If you must, obtain it from the “rv:x.y.z” string.

If you are presently using the build date or otherwise depending on the exact format of the “Gecko/yyyymmdd” token, stop! In the next major release of Gecko, this will be replaced by the string “Gecko/”. If you rely on the fact that this will be followed by a date string, you will break.

For testing purposes, the unfrozen build date is still included in nightly builds of Firefox, but it will be removed in future nightly builds.

7) For Gecko-based browsers other than Firefox, the way they identify themselves has changed. For instance, this is what it’ll look like for Fennec, the mobile version of Firefox:

Firefox token. This is a compatibility token that some Gecko-based browsers will use; for instance Fennec — and Camino (for Mac) — wish to appear like Firefox for maximum compatibility with websites. (The version portion of the string will generally represent the Firefox version corresponding to the given release of Gecko.) Now, this is an optional token that some Gecko-based browsers may not opt into. For this reason, sniffers should be looking for Gecko — not Firefox! For Firefox itself and other browsers that don’t opt in, this token will not appear, since it’s taken care of by:
Application. This will be something like “Firefox/4.0.1” for Firefox itself, or “Fennec/2.0.1”, or “Camino/2.1.1”. In addition, testing builds of Firefox (Minefield nightlies and prerelease builds) will now identify themselves as Firefox rather than Minefield.

It’s also worth noting why we didn’t change some things. The “X11” part of the Linux string may appear redundant, but it’s actually not: desktop machines are almost exclusively running X11, but Android phones are not, and Maemo (while X11-based) should be differentiated. For reasons like this, the various platform-specific parts of the string are important to know: there are different tokens for Windows 64 on x64, or WoW64 (a 32-bit browser on a 64-bit Windows); PPC or Intel on Mac OS X; and the various environments and architectures for Linux. Here are some examples of various Gecko-based browsers on various platforms:

Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (WindowsCE 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre

Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre

Mozilla/5.0 (Android; Linux armv7l; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Fennec/2.0.1
Mozilla/5.0 (Android; Linux armv7l; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre Fennec/2.0b1pre
Mozilla/5.0 (Maemo; Linux armv7l; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Fennec/2.0.1
Mozilla/5.0 (X11; Linux armv7l; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Fennec/2.0.1
Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Fennec/2.0.1
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Fennec/2.0.1
Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre Fennec/2.0b1pre

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Camino/2.2.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre Camino/2.2a1pre

There are some other important changes relating to how the UA string can be modified by external programs, Firefox addons, and users themselves. These changes will be detailed in another post, but the upshot is that the strings you see here are what you’ll see in the wild.

Now, if you’re a web developer, take note! All these changes will be in Firefox 4 Beta 6 (soon to be released), so if you want to be ahead of the game, you’re welcome to test against it. As noted above, for a complete list of UA strings to test against in all their glorious variations, see the link above and the text file. Happy sniffing!

47 comments

fearphage

The whole tone of this article is wrong. It sounds like it’s supporting and even advising browser sniffing which is something the browser community as a whole has been trying to leave in the past.

https://developer.mozilla.org/en/Browser_Detection_and_Cross_Browser_Support#Recommendations

September 9th, 2010 at 12:08
Nicholas C. Zakas

@fearphage – We will never get away from user-agent sniffing. We still need it on the server for any number of reasons, not the least of which is analytics. I can guarantee that every analytics tool developer finds this post incredibly useful in making sure that their data is correct.

If you read this article and thought that it was suggesting user-agent sniffing over feature detection, then I’m afraid you’ve read it completely wrong.

September 9th, 2010 at 12:15
ddahl

@fearphage Just because the new techniques of determining capabilities is superior and indeed encouraged does not mean that browser sniffing won’t be done any longer by developers.

Developers will be sniffing for years to come, and sites will break. This post is just being realistic about the issue.

September 9th, 2010 at 13:47
Robert Kaiser

Note that the Firefox compatibility token will be on by default in SeaMonkey 2.1 as well (though there will be a checkbox in advanced preferences to turn that off).

So, the DEFAULT SeaMonkey user agent string will be e.g.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 SeaMonkey/2.1.1

When users choose to deselect that checkbox, the Firefox token will be missing, but by default, it will be there.

September 9th, 2010 at 13:47
Robin

WTF, the locale is gone?! It’s used all over the web! And most other browsers include it in their user agent, afaik.

September 9th, 2010 at 14:34
1. Boris
  
  The locale isn’t used much, in fact. And IE doesn’t include it in its UA. So in fact “most” (by number of users) browsers don’t, and even more so now that we don’t include it.
  
  September 11th, 2010 at 07:31
Don Marti

Why such a detailed privacy leak to support a deprecated activity like browser sniffing that people always do wrong anyway. How about just

User-agent: mozilla.org

September 9th, 2010 at 14:53
Tony Mechelynck

«6) The Gecko build date in the “Gecko/yyyymmdd” token has been frozen to 20100101 for Firefox releases. The build date will be dropped entirely in the next major release, making the token just “Gecko” without the “/” or the date.»

Yeah, and thanks for the triagers and bugfixers who will, starting at the next major release, have no way to guess from a UA string (which is what Bugzilla displays in comment #0 of a bug filed through the “guided” form) in which changeset (of group of successive changesets) the bug appeared. This “fingerprint paranoia” is looking a little sillier to me at every turn. We’ll have to get a crash and rely on the “inside information” that Breakpad sneaks out to Soccorro, or we’re stymied.

September 9th, 2010 at 17:25
1. Boris
  
  Tony, for bugs you can reproduce you can bisect yourself, right? For the others, you can ask the bug reporter to copy/paste the changeset id from about:buildconfig, which is a heck of a lot more useful than the date anyway….
  
  September 9th, 2010 at 18:09
  1. Tony Mechelynck
    
    Yeah, sure, and how do I know whether http://hg.mozilla.org/mozilla-central/rev/ab4c25f8c9dd is before or after http://hg.mozilla.org/mozilla-central/rev/6fe4cb9f2a55 ? (Don’t look: I made them up.) With the build date of the last “good” and the first “bad” nightlies (no matter whether I can reproduce the bug or have to ask the reporter) I could immediately generate a regression window to within 48 hours of precision at worst; and with the “build ID” in the form yyyyMMddhhmmss (which, alas, is not in about:buildconfig) the window would be even more precise.
    
    Also, these mozilla-central Mercurial hashes are not much help if the bug happens to be somewhere in comm-central (for SeaMonkey, Thunderbird, Lightning) or even in some “smaller” repository (ChatZilla hg, DOM Inspector hg, Venkman hg, or LDAP CVS; with comm-central and mozilla-central that’s six different places from which SeaMonkey gets its sources).
    
    As for “bisecting” when I have no prior idea of the time frame involved, I’ve done it in the past (ftp, uninstall previous version, install newly downloaded version, test) and it’s a g****mn hassle: it would be better if I already had one “bad” timestamp (presumably near the “bug event” if it’s a regression) already displayed in the bug description. “hg bisect” is not applicable because of the six different above-mentioned repositories, and even if I could get all sources for a given date it would mean compiling on my own machine, much slower than the Mozilla builders (compiling SeaMonkey takes me typically 13 to 14 hours).
    
    September 9th, 2010 at 20:58
    1. Henry
      
      um, did you know that
      
      navigator.buildID
      
      exists for the purpose of identifying the build date?
      
      Cutting it away from the userAgent is smart. It prevents fingerprinting.
      
      Bugzilla can just use javascript to get buildDate.
      
      September 12th, 2010 at 01:36
David

Why can’t we scrap the User agent string? Or maybe make it actually parseable?

Mozilla/5.0, why do we still have this?
Why is the Gecko version included with the platform details rather than with to the Gecko token?
Why not just have:
(platform) (engine) (application)
(X11; Linux i686;) (Gecko/2.0.1) (Firefox/4.0.1)

Typically, all the UA string is used for these days is for browser stats, and maybe to detect mobile/touch capable browsers so that more appropriate content can be served. Ironically, hardware info is not included in the UA string, which makes detecting such browsers impossible without making assumptions about what device a particular browser would be running on.

September 9th, 2010 at 19:00
1. Tony Mechelynck
  
  What do you mean, “hardware info is not included in the UA string”? “Linux i686” in your example above, means you’re running a 32-bit version of the app on a 32-bit Intel-686 or compatible processor (and in a Linux OS but that’s software). Fennec or even (if possible) Firefox running on Maemo would have “Maemo; Linux armv7l;” instead of “X11; Linux i686;” shown above; IIUC armv7l represents the processor family.
  
  September 9th, 2010 at 21:18
  1. David
    
    Yeah, you can get some idea of the CPU if you’re lucky, but it tells you very little about the device itself (size of screen, touch capability, etc).
    
    September 9th, 2010 at 22:27
    1. Tony Mechelynck
      
      About the size of the screen, what is relevant to a browser is the size of the browser window, and that can be changed by one mousedrag; what concerns touch capability, I think that a touchscreen, a light pen, a touchpad or a mouse all “feel” the same to the software: they are all “pointing devices” and I would expect that the browser should get the same “events” from the OS whether you hit the screen with the tip of a finger or a light pen, or whether you tap a touchpad or click the mouse, so no, those should not be “important” characteristics. The first part of the platform is different for Maemo or Android than it is for Macintosh, X11 or Windows so you still ought to be able to tell whether you’re running on a smartphone OT1H or on a desktop or laptop with a full-size screen OTOH.
      
      September 10th, 2010 at 04:34
      1. Henry
        
        I don’t think Firefox can scrap “Mozilla/5.0” as many servers use this to identify browsers from bots.
        
        (to wt i remember, opera used to identify as Opera/ but they changed to Mozilla/5.0 after being blocked too much)
        
        September 12th, 2010 at 01:32
      2. Hans Walter
        
        @Henry: Nope, it’s Opera/… again. But then Opera also has this nifty browser.js
        
        September 13th, 2010 at 06:44
Thomas

Where is the Android Version information?

I think this is very important!
you deliver the Information about the Version for Windows and Mac, but not for Android? I think you should. The default Android Browser does it!

September 10th, 2010 at 00:05
Thomas

Please add the Version information for other platforms.

Here is an example of an Android user agent string:
Mozilla/5.0 (Linux; U; Android 2.1; en-us; Nexus One Build/ERD62) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

Also, where is the Information that, for example, Ubuntu sends going to be:

Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.9.2.8) Gecko/20100722 Ubuntu/10.04 (lucid) Firefox/3.6.8

September 10th, 2010 at 00:08
Ben Bucksch

When looking for Gecko, please look for “Gecko/”, not “Gecko” + “rv:”, nor “Firefox”.

Looking for “Firefox” is wrong, because it’s just the browser UI and makes no difference to the website. There are many other Gecko-based browsers, and they’d all be forced to say “Firefox”, which is insane.

Unlike Dan says, the UA string should not be changed to ” Gecko “, but to “Gecko/2.1”, a) because that’s what the standard suggests and b) because Safari also sends “Gecko”, so it’s important to keep the “Gecko/”.

September 10th, 2010 at 06:30
discoleo

> I would expect that the browser should get the same “events” from the OS whether you hit the screen with the tip of a finger or a light pen, or whether you tap a touchpad or click the mouse

But this is so programming-oriented, and basically so wrong. If I hit a touchpad with my fingers, I certainly will have some difficulty in fine control, e.g. selecting the letter “i” inside a word. From a usability perspective, if I have to navigate and record data using these different technical modalities, I would want to make the web page adapt and switch for e.g. to a monospace font inside a form, if I am using solely the touchpad.

September 10th, 2010 at 08:12
1. Tony Mechelynck
  
  I would want to make the web page adapt and switch for e.g. to a monospace font inside a form, if I am using solely the touchpad.
  
  Easy: on that machine, find the chrome/ subdirectory of your browser profile, and create or modify the file userChrome.css in that folder, so that it contains (for example) the following CSS rule:
  
  input, textarea { font-family: monospace !important; font-size: 125% !important }
  
  to give all single- and multiple-line input fields a monospace font 25% larger than the surrounding text (or than whatever the font size is in the “containing” HTML element).
  
  September 10th, 2010 at 08:43
  1. Tony Mechelynck
    
    oops: userContent.css
    
    September 10th, 2010 at 08:44
    1. David
      
      >Easy: on that machine, find the chrome/ subdirectory of your browser profile, and create or modify the ….
      
      Easy? For you and I, yes, for the average user, no. It’s also something that content providers can’t do anything about. Expecting someone to go through each browser profile to fix things on every machine they use is quite frankly, ridiculous.
      
      > I think that a touchscreen, a light pen, a touchpad or a mouse all “feel” the same to the software
      
      No they don’t “feel” the same to the software. There are separate event handlers for touch events. There are certain things you can’t do with touch (double-click, middle mouse click) that you can with a mouse, and there are certain things you can do with touch (multi-touch gestures) that you can’t do with a mouse.
      
      Making assumptions about hardware based on the OS has the exact same problems as making assumptions about a browser’s capabilities based on the browser engine.
      
      September 10th, 2010 at 17:10
Boris

Tony, the date-based windows were never very good due to clock skew.

With the two changeset ids, you can just ask pushlog directly for all the pushes between the two and get an exact changeset window.

September 11th, 2010 at 07:29
Don Marti

EFF article on how this kind of micro-detailing in User-Agent facilitates user tracking.

http://www.eff.org/deeplinks/2010/01/tracking-by-user-agent

September 11th, 2010 at 07:41
Stephen Z

Essentially, the problem isn’t the user agent string itself but who receives it — but as long as 3rd party sites (e.g: ads) can get a hold of it, I’d argue it’s better to cut it down to pretty much nothing and let javascript (which at least can be enabled/disabled selectively via NoScript) do the “what OS/platform/rendering engine are you using” heavy lifting.

I guess I’m glad it’s shorter with 4.0, but the privacy implications make me want it as close to “gone” as we can get it. “Mozilla/5.0 Firefox 4.0” would suffice, I think.

September 11th, 2010 at 13:11
1. Tony Mechelynck
  
  Well, set general.useragent.override to the empty string (manually or via the UserAgent Switcher extension), or, if that doesn’t work, to a single space character, and your UA string will be gone. But considering some of the above replies, I guess you’d prefer at least “Mozilla/5.0” to avoid being confused with a bot and blocked out of many sites.
  
  September 13th, 2010 at 03:44
  1. Stephen Z
    
    Tony,
    Thanks for the suggestion, but the problem is that if a user (e.g: me) does change their user agent string to something non-standard, it only serves to make my browser more identifiable and easier to track. Not vice versa.
    
    It’s a simple matter of anonymity: the more people that have the same user agent as me, the better. My response would be that the default user string should be as non-specific as we can make it. The mozilla tag to declare that it’s a browser (for compatibility). Firefox with one minor version (e.g. 3.6) for some guess at site compatibility. Perhaps an extra string (“mobile” or “touch”) to designate the target UI form factor. But nothing else, leaving Javascript to handle the rest.
    
    The only alternative I can think of is to simply not send the user agent in requests to 3rd party sites and scripts.
    
    September 13th, 2010 at 13:55
    1. RCL
      
      What’s wrong with sending more info? It’s nice to see from the logs who visited your site, which platform they run, etc.
      
      September 24th, 2010 at 11:34
      1. RSE
        
        “What’s wrong with sending more info?”
        Privacy should be default. Anyone who wishes to send more information should have the option to do so.
        
        December 7th, 2011 at 02:39
Thomas

I filed a bug on the missing Android version information:
https://bugzilla.mozilla.org/show_bug.cgi?id=595669

September 12th, 2010 at 09:45
Hans Walter

> In the next major release of Gecko, this will be replaced by a string containing the Gecko version: “Gecko/x.y.z”. If you rely on the fact that “Gecko/” will be followed by a date string, you will break.

> If you must, obtain it from the “rv:x.y.z” string.

I am confused. Does this mean that there will be two ‘Gecko/…’ strings in the future, one with ‘rv’ and one without?!

September 13th, 2010 at 06:49
John

I would strongly suggest adding Windows; back into your windows UA. Removing it makes the windows Firefox UA inconsistent with Firefox’s UAs for other OSes. Consistency is VERY helpful when programming.

September 14th, 2010 at 11:26
gialloporpora

I have a question, in previous version of Firefox, I change this preference:
general.useragent.vendor

to specify the exact Linux version, for example Ubuntu/10.4 ecc…, now, in Firefox 4, this preference not works anymore,
Is it expired? There exists still the possibility to modify the user agent string to insert the OS version?

March 17th, 2011 at 11:25
1. Tony Mechelynck
  
  In Firefox 4 (and Thunderbird 3.3, SeaMonkey 2.1, etc.), all general.useragent.* preferences have become inoperative, with one exception: you can still use general.useragent.override to replace the *whole* user-agent string (but it is not recommended).
  
  This means that under Linux, all you normally get is either “X11; Linux i686;” or “X11; Linux x86_64;”. No more detail than that, and your Ubuntu and my openSUSE will get the exact same string (from the same browser version) unless one of us runs a 32-bit version and the other a 64-bit one.
  
  March 18th, 2011 at 09:30
  1. Peter D
    
    in FF up to 3.6.x we used this entry in prefs.js:
    user_pref(“general.useragent.extra.myblabla”, “BlaBla”);
    It extends the useragent with an additional string. We used this entry since FF 1.5 but FF 4.0 ignores this entry.
    
    i dont want to override the hole string. is there any trick to get back the old funktion?
    
    March 21st, 2011 at 23:59
    1. Hemilton
      
      No and changing the user agent string in any way is strongly discouraged. Just don’t do it.
      
      March 22nd, 2011 at 09:24
    2. Tony Mechelynck
      
      No, there isn’t. Unless you want to remain with Firefox 3.6.x or earlier, SeaMonkey 2.0.x or earlier, etc. See https://bugzilla.mozilla.org/show_bug.cgi?id=581008 for details.
      
      March 22nd, 2011 at 16:31
Alenônimo

I think browsers should get rid of the “Mozilla/5.0” part and use their real name or engine on it’s place.

March 31st, 2011 at 16:15
1. Rihards
  
  Agreed.
  
  March 31st, 2011 at 19:16
Travis

Those of you who think browser sniffing is evil obviously have never built websites that need to render correctly in IE6-9, Firefox, Safari, Chrome and Opera. Let alone ones that render properly with the previous along with smart phones.

Ex: IE6 doesn’t support transparent PNGs. All designers know this so what’s wrong with checking for IE6 and then doing something different with the imagery?

April 1st, 2011 at 10:47
gialloporpora

Today, I have tried Firefox 5b1, and I have noted that A string is still changed, my string is:

Mozilla/5.0 (Windows NT 5.1; rv:5.0b1) Gecko/20100101 Firefox/5.0

and, now, the “real” version (5.0b1) is in the place of Gecko version. Is this change effective?

I ask this, because in the italian forum of Mozilla, we use a plugin to show a nice version of the user agent (it could be useful sometimes with users that give few informations about their system) and, now, Firefox 5.0b1 appears like a Firefox 5.0, and I would like to know if this change is effective since I change the plugin code to detect the exact version in new Firefox.
Thanks

May 5th, 2011 at 09:55
1. Tony Mechelynck
  
  There has been changes in the versioning system of Firefox and Gecko recently. What you have there is “Firefox 5.0”, the current Aurora build,of unknown date (notice 20100101 which cannot be truthful) and built upon Gecko 5.0b1. My SeaMonkey build has its UA set to:
  
  Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110417 Firefox/6.0a1 SeaMonkey/2.2a1pre
  
  meaning SeaMonkey 2.2a1pre, parallel to Firefox-Nightly 6.0a1, and built on 17 April 2011 based on Gecko 6.0a1. Somewhere (I don’t know exactly where, but the Nightly Tester Tools extension can find it) it knows that its codebase was pulled on 2011-04-17 at 00:30:06 Mountain View time.
  
  May 6th, 2011 at 07:57
Cristian

Detect all possible browsers like: proxies, desktops, tablets, mobiles and applications (java, symbian, android). This is the best code ever, enjoy ;) http://code.google.com/p/detect-real-user-agent/

July 6th, 2012 at 23:07
Astrid

Do you mind if I quote a couple of your posts as long as I provide credit and sources back to
your site? My website is in the very same niche as yours and my users would genuinely benefit
from a lot of the information you provide here. Please let me
know if this ok with you. Thank you!

September 13th, 2012 at 06:19
Chloe Vevrier

Greetings! Very helpful advice in this particular article!

It is the little changes that produce the biggest changes.
Thanks a lot for sharing!

December 18th, 2012 at 14:42

Comments are closed for this article.

By

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.