3

I was looking for a way to identify the IE with JavaScript and suddenly, I noticed that the browsers, were identified as Mozilla:

Opera

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36 OPR/17.0.1241.53

Chrome

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

IE

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

Now I'm wondering why this browsers are identifying as Mozilla

  • 3
    Duplicate of [Why "Mozilla" string is present on all browser's User Agent?](http://stackoverflow.com/questions/1114254/why-mozilla-string-is-present-on-all-browsers-user-agent) – CBroe Nov 26 '13 at 11:37
  • 1
    If there's a specific reason why you feel you need to detect IE using Javascript, you should mention it (maybe in a separate question), as in most cases you can (and should) solve the problem some other way. – Spudley Nov 26 '13 at 12:48
  • @CBroe The system don't show me this question. – Vinicius Monteiro Nov 27 '13 at 11:15
  • @Spudley Thank you for showing interest, actually I was trying to find a way to fix a bug in IE9, because he can't render an object with a gradient background and rounded borders. This is all the fault of the filter, kkkkkk. I was with my back to the wall, but now repaired, thank you anyway. – Vinicius Monteiro Nov 27 '13 at 11:26
  • 1
    Ah yes, that's a pretty well known bug. I've answered questions about it here myself in the past. It sounds like you've got it resolved, but just in case you're still looking for answers, the best solution I know of is to use CSS3Pie for the gradients rather than IE's filter. – Spudley Nov 27 '13 at 11:29

1 Answers1

9

This is a result of the never-ending war between site developers and web browsers.

Every time a browser comes out with a new feature, developers want to use that feature. But they also need to handle browsers that don't support it.

The most obvious way to do that is often to use the UA string. Look for the browser you know supports the feature, and run your code accordingly. Easy.

Except it isn't that easy, because inevitably what happens is that a few months later the same feature is supported by the other browsers.

So now the other browsers have a problem: Sites are written to use a feature that they support, but those sites only activate the feature for one particular browser.

The solution for the browser vendors: Modify their UA string so that it fools the sites into activating the feature.

This kind of thing has been going on since the 1990's, when IE and Netscape fought the "Browser Wars" ("Mozilla" was Netscape's unique UA string name, so everyone else copied it into their UA string for compatibility), and has continued right through to today (When IE11 was released, its UA string was completely different to IE10's UA string, and this was done specifically in order to break browser sniffing code).

The end result is that the UA strings of all the major browsers are a complete mess. They are full of weird things like the names of their competitors, incorrect version numbers, multiple version numbers, and other obscure references, all aimed at fooling any script that is foolish enough to try to read it. Yes, it might be just about possible to parse it and get reliable browser detection, but it'll probably break again as soon as any of the browsers releases a new version.

On top of that, just to add to the confusion, most browsers also offer config settings to give the user the ability to change the UA string; and some third party products (anti-virus, firewalls, proxies, etc) are known to modify or replace UA strings as well, all of which makes it even less likely that you'll get a reliable response from parsing it.

So what's the take home message from all of this?

Your best best as a developer is simply to ignore the UA string entirely. It is virtually worthless to you for any practical purpose. If you need to use features that may not be available in all browsers, you are generally better off doing feature detection rather than sniffing the UA string (you might want to consider the Modernizr library for this).

Just pretend the UA string doesn't exist, and your life as a developer will be a whole lot easier.

Spudley
  • 166,037
  • 39
  • 233
  • 307
  • 1
    Nice rant, agree with most of it (+1), except that it's "all aimed at fooling any script that is foolish enough to try to read it" is a bit harsh - it makes it sound like the evil browsers are trying to trick the clever developers. Usually, it's more of a case of browsers trying to work around perceived limitations imposed by short-sighted developers/webmasters who blindly copy browser-sniffing code without really knowing what detrimental effect that has. – Amos M. Carpenter Nov 27 '13 at 00:45
  • 1
    @Spudley Excellent answer, I liked the way you explained, in fact we should avoid using features from a single browser, should be as generic as possible, but sometimes we are forced to use some ugly hacks so you can have the best possible effect. How ever IE putting me back against the wall. – Vinicius Monteiro Nov 27 '13 at 11:39