Introducing IE9’s User Agent String


This post introduces IE9’s User-Agent (UA) String and it builds on previous blog posts and documentation.

An important change for site developers to know is that IE9 will send the short UA string by default. This change improves overall performance, interoperability and compatibility. IE9 will no longer send additions to the UA string made by other software installed on the machine such as .NET and many others.

Some folks will notice that the IE9 Platform Preview sends IE8’s UA string. We will include the new IE9 UA string in an upcoming Platform Preview update. The reason we’re writing about IE9’s UA string now is to give site developers an early preview of these important changes and time to verify that any current UA logic continues to work with the new IE9 UA string.

IE9’s default UA string

There are four changes to IE8’s UA string that site developers need to be aware of:

  1. Application version is incremented from ‘Mozilla/4.0’ to ‘Mozilla/5.0’ to match other browsers (explained well in the great History of the user-agent string post). This change signals that IE9 is an interoperable browser.
  2. Version token is incremented from ‘MSIE 8.0’ to ‘MSIE 9.0’.
  3. Trident token is incremented from ‘Trident/4.0’ to ‘Trident/5.0’.
  4. IE9 will send the following short UA string without additions made by other software installed on the machine:

breakdown of the different parts of the UA string

IE9 will send the short UA string by default

We’ve received many reports  on compatibility issues due to long, extended UA strings. IE9 will send the short UA string detailed above without pre and post platform registry value tokens. This is interoperable with other browsers, and improves compatibility and network performance.

Applications and platforms can continue to add to the UA string through the pre platform and post platform registry keys as they did in previous IE releases. IE9 will not change existing registry values.

Websites will continue to be able to get the extended UA string with pre and post platform tokens through the navigator.userAgent property.

IE9’s Compatibility View UA string

Similar to IE8, IE9’s Compatibility View will map to IE7 Standards Mode, and IE9’s UA string when in Compatibility View will be:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0)

In Compatibility View, IE9 reports itself as IE7 through the application version number (Mozilla/4.0) and version token (MSIE 7.0). This is done for compatibility. An incremented Trident token, from ‘Trident/4.0’ to ‘Trident/5.0’, allows websites to distinguish between IE9 running in Compat View and IE8 running in Compat View.

Request for site developers

Test how your site responds to the new IE9 UA string (check and change the UA string through the registry). If your site doesn’t already respond with IE-compatible content, we’d love to see it updated now to recognize IE9 and be future-proof.

Marc Silbey
Program Manager

Comments (94)

  1. Anonymous says:

    Excellent work on maintaining the good old user agent hell. Why do you still use "Mozilla"? And why do you call it "application name"??? What’s this bullshit? I thought application name is IE and version is 9.

    And I thought, that starting with IE8 you’re moving away from the browser war phenomenons.

    And people, please, drop this ridiculous argument that it would cost. What really costs is a bad legacy and your bad practices, like browser sniffing. Hey, it’s 2010.

  2. Anonymous says:

    @Clue:

    Touché. What a well-reasoned and cogent argument against… something. Or maybe in favor of nihilism?

    **slow clap**

  3. Anonymous says:

    I suggest:

    Internet Explorer 10=IE9+virtual pc

    the virtual pc provide a MiniWin OS(like windows XP) which can:

    1 a regulation for auto downloading win32 exe and dll run form IIS.

    2 for each web app,give a proper sandbox for security.

    3 communication with other common web page.

    4 isolated virual disk,virtul memory for each web app(exe,dll)

  4. Anonymous says:

    I suggest:

    Internet Explorer 10=IE9+virtual pc

    the virtual pc provide a MiniWin OS(like windows XP) which can:

    1 a regulation for auto downloading win32 exe and dll run form IIS.

    2 for each web app,give a proper sandbox for security.

    3 communication with other common web page.

    4 isolated virual disk,virtul memory for each web app(exe,dll)

  5. Anonymous says:

    @EricLaw

    Why not commit now on dropping the Mozilla compatible string for next IE version and replace it with Trident or with MSIE.

    And kick those idiots from ASP.net for their inability to read "MSIE" in the UA string still so that hey will change this ASAP to recognize IE9 and up trough that string.

  6. Anonymous says:

    @Eric –

    "Per the Phone team, Windows Mobile 7 will ship with an engine that is "halfway between IE7 and IE8 rendering engine.""

    What the HELL describes halfway between 2 versions?  REALLY?!?!?!?  This has got to be an early April Fool’s day gag, surely.  You can’t possibly (you as in Microsoft) expect people to code to something like that.

  7. Anonymous says:

    > I do not believe this claim

    > I consider it a big mistake

    so what, WTFAY?

  8. Gaurav says:

    Will an "IE8 View" be available for developers, and if so what will the UA string be?

  9. Tom Stack says:

    Please do away with the Mozilla token, its legacy, many wanted to see it gone in IE 8, please get rid of it.

  10. Rob says:

    @Tom, cost vs benefit comes into play… What’s the cost of removing it? All that code out there that expects "Mozilla" needs changing, all the places in IEs test-code need changing, etc,.. What’s the cost of leaving it in? Nothing, nada, zilch.

    I’m well aware of the almost religous fervour that this particular topic can cause – but I really don’t understand it. For something that really doesn’t matter, it does seem to get people quite worked up…

  11. Matt says:

    If you get rid of Mozilla, you can also get rid of "compatible"– both the word in the string, and the behavior on the real-world web.

    Removing these words from the UA breaks browser sniffing on any site using ASP.NET or any other popular User-Agent detection framework.

    Rather high price to pay.

  12. Typhoon87 says:

    Will we actually have to have 4 rendering modes in the final version? IE5 "quirks", IE 7, IE8 and Standards, Or will it just be IE 8 or standards?

    Some legacy do you dont break everything is okay but 4 modes would simply be overkill.

  13. boen_robot says:

    What about the "Win64; IA64", "Win64; x64" and "WOW64" platform modifiers? Will they be present?

    I sure hope they would, as it would enable detecting 64 browsers and OS-es on the server side, enabling sites to deliver targeted content at them more easily, and possibly, more efficiently (depending on the use case).

    Besides, those modifiers are more useful (and less privacy intrusive) than the .NET or other application specific tokens.

  14. G. Wurst says:

    So no IE8 mode for IE9?

    @Tom Stack

    The ‘Mozilla’ in the user agent is in honour of Netscape. Microsoft even bought the Netscape’s old trademark "Live" because they love them so much.

  15. zzz says:

    According to EFF’s site panopticlick.eff.org, the User Agent string contains the most bits of uniquely identifying information. When using IE8 with all kind of RC/BETA .NET version information together with the other info, it makes you very uniquely identifiable.

    Browser, Characteristic bits of identifying information, one in x browsers have this value

    User Agent, 17.94, 251727.33

    HTTP_ACCEPT Headers, 19.53+, 755182

    System Fonts, 19.53+, 755182

    Now I wouldn’t pay too much attention to the values, just that those are the three biggest identifiers. When IE8 is changed to use "InPrivate browsing" the values dropped to half despite the value according to the site staying the exact same so I think their code may have some bugs.

    How can I force IE9 to restrict these fields that it send. I don’t think most web sites need to know the exact version of all various .NET pieces and the long list of system fonts.

  16. Will Peavy says:

    @Marc Silbey – thanks for the .reg file.

    UA sniffing is being used at: http://browserscope.org/

  17. MarcSil [MSFT] says:

    @Gaurav: IE8 Standards Mode is available for websites to opt-into through the X-UA-Compatible meta tag and HTTP header such as <meta http-equiv="X-UA-Compatible" content="IE=8>. IE sends the IE9 UA string to servers and parses the meta tag for IE8 after receiving the webpage.

    @Tom: There will be IE5, IE7, IE8 and IE9 Document Modes. You can try these out now using the Debug menu options in the Platform Preview build.

    @boen_robot: Yes, the platform token will continue to include 64bit identifiers such as WOW64.

  18. Brianary says:

    Yay! The short UA string is *excellent* news!

    Re: The cost of leaving in "Mozilla/5.0 (compatible;"?

    It just takes longer to parse. Every time. Times millions of log entries.

    Is it the end of the world? Probably not.

    But there’s also a tipping point after which user agent sniffing should be more actively be discouraged, since it’s such a stupid method to use for progressive enhancement or graceful degradation. It’s unnecessarily complicated, unreliable, and high-maintenance, at least when compared to the modern feature-testing method.

    BTW: There’s a much better history of the user agent string at http://webaim.org/blog/user-agent-string-history/

  19. Brianary says:

    Wow. FOUR rendering engines‽ Just… wow.

  20. The ‘Mozilla’ string seriously needs to be dropped. It probably wastes gigabytes of hard drive space every day if not more in access logs alone and a web server should determine XHTML’s application/xhtml+xml support via the HTTP accept header, NOT the user agent. Don’t want to break the web? Then don’t allow inexcusably wrong practices.

    Regardless it *is* awesome to see IE finally supporting XHTML *however* the HTTP accept header has not been updated for at least the initial public build of IE9 though I’m pretty sure that it’ll be resolved reasonably soon: https://connect.microsoft.com/IE/feedback/details/542437/http-accept-header-too-vague-needs-application-xhtml-xml

    But it’s an early build and the approach to improving the wide range of specifications is commendable considering the bigger picture. So good job on everything so far and I’m looking forward to those reasonably frequent updates!

  21. JC says:

    You see, not everyone is a web developer. Users like me are more interested about what the IE9 UI will look like, whether there will be a built-in download manager and spell-checker etc. Please tell us more about those issues.

  22. naruse says:

    Hi, Why trident token is in comment?

    and wander about next IE9, his user agent contains "MSIE 10.0"?

  23. hAl says:

    It would have been nice if you had dropped the mozilla compatible part of the UA string.

    At least announce that this is the last version to have that string in it or something.

  24. hAl says:

    I have just checked quite a few sites to find a site sniffing for Mozilla. It took me between twenty and thirty to find one and that site did it on Mozilla/4.0 to deliver content for IE6.

    I can’t imagine many sites snifffing for Mozilla/5.0. Inf fact I find it highy unlikely and Microsoft should remove the mozilla compatiblity ASAP.  

  25. George Wurst says:

    @Brianary: [OT: First time I see someone using an interrobang]

    Anyways, I wonder if they managed to implement all four rendering engines without breaking the DRY principle…

  26. George Wurst says:

    Apropos user agent sniffing is bad, the following shouldn’t be an alternative:

    var IE4 = document.all;

    var NS6 = document.getElementById && !document.all;

    Guess where I found this? On this very site…

  27. vasek7 says:

    I think user agent string should be like this:

    Trident/5.0 (MSIE 7.0; Windows NT 6.0)

    In the worst case server will not recognize IE9 as IE browser and will serve Firefox/Opera/Safari version of HTML code. IE9 is compatible with that HTML code in the most cases, isn’t it? On the client side, IE is often detected by conditional comments or by testing of document.all object, so there is no problem.

  28. BigFail says:

    Why are you guys doing yourself such a disservice by limiting your browser adoption to the underlying platform? You don’t IE9 to exceed the marketshare of Vista and Windows 7? All other browsers are targeting 100% Windows customers AND then some Linux and Mac users. It’s not as if the world would come shattering down if IE9 on XP doesn’t support hardware acceleration. It just shows how much importance MS gives after all has happpened to standards compliance. Standards support is still not No.1 priority or maybe No.2 after security. It’s No.3 priority. Locking your browser to Windows 6.x family of OS is one of your top priorities.

  29. John-Wayne says:

    My two cents…

    I found no site that scan explicit for this mozilla string too. And on the other side:

    a)IF text==MozillA THEN… this implicit that there are browsers with text==XYZ…

    Or why should a site always check for the same value from all browsers?

    b)It’s another thing if Opera with 1-5% market share do this or the IE.

    c)someone wrote above something about ASP.NET.

    The ASP programmer really handle this Mozilla string or is this only ASP.NET internal? I guess not. And if this is ASP internal, ASP is from MS too, what’s the problem?

  30. Gary says:

    I think we’re getting to a stage that sniffing for feature-support has been around long enough that sticking to legacy practices to support it in future applications is a little pointless.

    Those web apps that use it (assumed to be built in the IE6 era) will probably need work done on them to make them work with IE9 anyway, at which point that can move away from relying on UA-strings. This, in turn, shows why it’s high-time the backwards-looking format of UA-strings be dropped.

  31. anony.muos says:

    Windows XP in many ways is not a nine year old system, with the larger than life updates in SP2 and SP3 which has extended the system beyond it’s org launch in 2001.

    Windows XP has been in the market longer than any other OS from Microsoft and thus will take a long time to replace.

    For people stating that there is no difference between Win98 + IE6, remember that XP is still supported by Microsoft and has only been replaced since 2007 on the Vista launch. There are many companies that have a perfectly good WinXP + Security Suite + Other Software setup, they could pay a lot of money to perform the upgrade however they are not going to gain a massive amount from switching from XP to Win7, if people on the network can still log on, perform their office work and then log off, what do they need to upgrade?

    Of course i am not blind to the advantages of running a Win7 + Win2008 R2 AD with branch cache, bitlocker etc.. However it is a massive undertaking and a lot of companies will plan to roll this out over the coming years as SP1 is coming up for release.

    Unless there is a really good specific reason (The GPU thing im sure could have been in DirectX 9) i think it would have been in Microsoft’s best interests to release 9 for XP aswell and then make 10 Vista/7+ only. IE9 would have slotted into this period of time where companies are starting to think about upgrading and would have kept the browser presence. Of course XP users can stick to IE8, however with the improved HTML5 and better compliance it would have made a good upgrade to XP aswell.

    Im not against Windows 7, i use it as my primary work OS on both my desktop and laptop and it performs admirably. I also have some Win2008 R2 servers and the improvements are unreal. However rolling this out across the network is a different and bigger project to think about and plan.

    From a consumer point of view i don’t think anyone is going to upgrade their machine to Windows 7 for IE9. In the consumer space there is only a small percentage who perform upgrades the rest purchase their OS with a new machine. So for the people left and think they are being left behind, they will move to a different platform, firefox or chrome. This in turn could keep people with alternatives even when they upgrade to Windows 7.

  32. John-Wayne says:

    It’s not only this DirectX 9, e.g. Windows XP and IE8.0 have no prodect mode.

  33. Stifu says:

    @someone: most companies have been staying with IE6 all this time and were happy with it, so I doubt they’ll be too bothered if they can’t go beyond IE8.

    For the record, mine will upgrade from IE6 to IE8 this year, like some other companies I know.

  34. Gary says:

    Please ensure that the .Net teams remove every single bit of garbage from this string that they add.

    e.g. all this garbage!

    ".NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

    I believe Chris Wilson (or was it Eric Lawerence) MSFT has spoken strongly about the abuse the .Net team has applied to the user agent string.

    If IE9 is fixing up so much of its bad legacy code/issues/support – please ensure this gets fixed too!

  35. EricLaw [MSFT] says:

    @Gary, zzz: As Marc outlined in his post, none of the .NET identifiers or other "post platform tokens" will be sent to the server in the IE user-agent.

    Folks calling for the removal of Mozilla and Compatible strings need to consider the point made by Rob and Matt– doing so will cause significant problems for a significant number of sites. As before, I welcome folks to try out proposed UA strings against all of their favorite sites (http://www.enhanceie.com/ietoys/uapick.asp) while keeping in mind that there are millions of other sites that matter a lot to other people.

  36. Gyrobo says:

    I believe this is finally the correct topic to air my previous comment [1] requesting a historical accounting of Trident’s versioning scheme. While Trident versions 4.0 and 5.0 are public knowledge (as well as the nascent Trident 3.1 [2]), older versions are unknown. Which version of Internet Explorer contained Trident 1.0? Was there even a versioning scheme prior to the release of IE8?

    Furthermore, are you planning a complete rewrite of the UA string in the future to avoid the same problem Opera ran into at version 10 [3]?

    [1] http://blogs.msdn.com/ie/archive/2010/02/22/mix-microsoft-w3c-and-svg.aspx#9968262

    [2] http://www.neowin.net/news/windows-phone-7-browser-is-based-on-internet-explorer-7

    [3] http://dev.opera.com/articles/view/opera-ua-string-changes/

  37. Mitch 74 says:

    You should remove ‘mozilla’ and ‘compatible’ in IE9 mode, for they are no longer needed:

    – you already have a "compatible" mode, that people seem able to use. If they can’t access a website with IE 9, they can switch to Compatibility mode, and be done with it. That’s how Opera does it now, after all. It seems to be working.

    – due to IE’s spoof of ‘Mozilla’, recent websites don’t really try to discriminate between browsers through the Mozilla string; since you have a ‘modern’ browser, you can advertise your engine. Those that do, would require compat mode anyway. Actually, I bet you there are more websites punishing ‘Mozilla’ strings with ‘Trident’ in it than others – say, one starting with a product name that ain’t ‘mozilla’.

    – that is a cheap but efficient way to say, "we’re more standards-compliant than Webkit, eat that Apple and Google!"

  38. Thomas Tallyce says:

    I would agree with the majority of other posters here that it’s time to drop the Mozilla token. How many sites are REALLY changing the code they issue based on whether "Mozilla" is present, given that it’s basically meaningless these days. Things work fine on other browsers that are now dropping it.

    Given also that IE is going to have to come up with a solution for IE 10 (which Opera has also been facing), now is the best time to dump the legacy and give IE its own user-agent string.

    How about

    Microsoft Internet Explorer 9.0; Windows NT 6.1

    Isn’t that simple enough? If people really need to test again Trident 5.0 (which again, I think unlikely) then they can just test against the first bit instead, so I don’t see why it needs to be listed instead.

    Making this change NOW should give site owners a good 6-12 months to fix their sites if they’re really using this stuff, which should be enough time.

  39. Mitch 74 says:

    @Thomas: parsing strings with lots of spaces is a pain; so, MSIE or ‘Trident’ allows for much easier parsing, and is shorter too.

    I’d rather parse:

    TRIDENT/5.0 (Windows NT 6.1; U; MSIE 9.0; fr-FR)

    though…

    that would also allow browsers using IE’s engine to be more simple to detect:

    TRIDENT/5.0 (Windows NT 6.1; U; Maxthon 27; en-US)

  40. Will Peavy says:

    What about using "TRIDENT/5.0 (Windows NT 6.1; U; MSIE 9.0…" in IE9 standards mode, with a fallback to the Mozilla UA for quirks/compatibility modes?

  41. Brianary says:

    I’m sure Microsoft (and possibly others) maintain a list of sites that still perform browser sniffing.

    It’s time to name and shame.

    Not because of this particular issue, but because it’s a stupid, high-maintenance, complex, and unreliable practice that stifles innovation and locks out current and future browsers from information, and locks corporations into ancient, insecure software like IE6.

  42. Clue says:

    blah blah blah blah blah blah.

    Anyone can play browser designer, but hopefully you realize that nothing proposed in these comments is going to come to pass.

    Go read the comments on every past post on the user-agent string; we’ve all been here before, and the monday morning quarterbacking was pretty boring then too.

  43. EricLaw [MSFT] says:

    @Gyrobo: No, there wasn’t a public versioning scheme for Trident prior to IE8. While MSHTML.DLL had a version number, it had no particular meaning. For IE8, Trident was declared to be 4.0, and now for IE9, Trident is declared to be 5.0.

  44. Brianary says:

    Mitch 74 has a pretty good idea regarding dropping Mozilla/5.0 for IE9 mode.

    IEBlog guys, of the sites requiring "Mozilla/", how many are going to be OK with "Mozilla/5", and how many require "Mozilla/4"?

  45. @Brianary: I’m only have a test page for one browser detection framework used by millions of sites; that provided by ASP.NET.

    Using the little UA-switcher tool to change my UA and visit http://www.enhanceie.com/ua.aspx, I see the following results:

    ==============
      Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
    ————–
    ASPNET’s HTTPBrowserCapabilities object reports that, based on the User-Agent, your Browser has the following capabilities:

    Type = IE9
    Name = IE
    Version = 9.0
    Major Version = 9
    Minor Version = 0
    Platform = WinNT
    Is Beta = False
    Is Crawler = False
    Is AOL = False
    Is Win16 = False
    Is Win32 = True
    Supports Frames = True
    Supports Tables = True
    Supports Cookies = True
    Supports VBScript = True
    Supports JavaScript = True
    Supports Java Applets = True
    Supports ActiveX Controls = True

    ==============
      MSIE/9.0 (Windows NT 6.1; Trident/5.0)
    ————–
    ASPNET’s HTTPBrowserCapabilities object reports that, based on the User-Agent, your Browser has the following capabilities:

    Type = Unknown
    Name = Unknown
    Version = 0.0
    Major Version = 0
    Minor Version = 0
    Platform = WinNT
    Is Beta = False
    Is Crawler = False
    Is AOL = False
    Is Win16 = False
    Is Win32 = True
    Supports Frames = False
    Supports Tables = False
    Supports Cookies = True
    Supports VBScript = False
    Supports JavaScript = False
    Supports Java Applets = False
    Supports ActiveX Controls = False

    ========================

    Now, the immediate retort will obviously be “well, you just need to change ASP.NET and the other frameworks that detect browser capabilities.” And yes, that’s true, and then sites have to deploy the updates, and until they do, users have a bad experience and users shy away from upgrading to IE9 and then web developers cannot take advantage of the new features, and older browsers live on for longer than they would if we had provided a higher degree of initial compatibility. No one wants that. 

  46. @EricLaw [MSFT]

    Regarding Mozilla and Compatible strings removal, you say that

    "doing so will cause significant problems for a significant number of sites."

    UA string detection on "Mozilla" is considerably rare, I’d say. UA string detection on "compatible" is furthermore rare, I’d say.

    Site owners could check their sites in the next 12 months. MSDN could write an article helping, assisting web authors on best practices on browser feature/method detection to replace browser sniffing: a lot of people already explained, repeated all this.

    Site owners could test their sites while IE9 beta 2 is released. Etc, etc.

    IE is the only browser that has, uses and creates many browser and/or document and/or engine detection features: meta-tag, managed lists, document modes, browser modes, compatibility buttons, switches, settings, documentMode, etc.  on top of what other browser do: doctype switching, compatMode, etc. Just unbelievable.

    @George Wurst

    var IE4 = document.all;

    var NS6 = document.getElementById && !document.all;

    Of course, MSDN and all Microsoft-controlled websites use, reuse and overuse bad coding techniques like that. It’s been like that for well over 10 years now. Any careful observer will find lots of coding errors, bad practices in many MSDN articles.

    @BigFail

    > Why are you guys doing yourself such a disservice by limiting your browser adoption to the underlying platform?

    The development of IE8 was surely an expensive one. Microsoft needs more money to sustain IE9 development (and its other products) and satisfy its share holders. Within such frame of mind, IE9 becomes one incentive to increase Windows 7 sales and eventually Windows 8 sales.

    > All other browsers are targeting 100% Windows customers AND then some Linux and Mac users.

    One poster suggested to make an IE9 for Linux and Mac platforms. I doubt Microsoft will do that.

    > It’s not as if the world would come shattering down if IE9 on XP doesn’t support hardware acceleration. (…)

    The extended support for XP Home (SP3) and XP Pro (SP3) is supposed to end in april 8th 2014…

    regards, Gérard

  47. EricLaw [MSFT] says:

    <<UA string detection on "Mozilla" is considerably rare, I’d say.>>

    Would you mind pointing me to any data you’ve collected on the topic? I’m always interested in learning more.

    <<IE is the only browser…>>

    Yes, it’s true that the IE team invests more in compatibility than many other browsers do. We face a fascinating set of tradeoffs here, and other browsers are increasingly encountering the same tradeoffs as they grow their marketshare.

  48. @EricLaw [MSFT] Can we please get a list of those sites so we can start visiting them with Opera every five minutes? 😀

  49. Brianary says:

    @EricLaw: Actually, the immediate retort is "Why are you using HTTPBrowserCapabilities?"

    Are you really suppressing frames, cookies, &c. based on the UA in production code? Are you providing exclusive IsAOL-only content, or writing a lot of client-side VBScript?

    Are ASP.NET Forms controls (built-in or custom) making internal rendering decisions based on HTTPBrowserCapabilities? If so, are they still valid assumptions, as compared to actual modern browser capabilities?

    It seems to me that the only reason you’d use HTTPBrowserCapabilities would be when you needed to substitute *markup* code, and the only reason you’d still be doing that is if you wanted to offer *future* support, such as choosing between complex Flash Satay or the HTML5 video tag, say. And support for (near-) future tech like that already requires significantly reworking the Browscap database and codebase.

    The real problem of browser variance exists at the DOM level, and that’s just not a server-side problem.

  50. Will Peavy says:

    What about this one?

    User-Agent: Mozilla rules! (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)

    ———————————————-

    ASPNET’s HTTPBrowserCapabilities object reports that, based on the User-Agent, your Browser has the following capabilities:

    Type = IE9

    Name = IE

    Version = 9.0

    Major Version = 9

    Minor Version = 0

    Platform = WinNT

    Is Beta = False

    Is Crawler = False

    Is AOL = False

    Is Win16 = False

    Is Win32 = True

    Supports Frames = True

    Supports Tables = True

    Supports Cookies = True

    Supports VBScript = True

    Supports JavaScript = True

    Supports Java Applets = True

    Supports ActiveX Controls = True

  51. Quiet Developer says:

    @EricLaw [MSFT] "Yes, it’s true that the IE team invests more in compatibility than many other browsers do. We face a fascinating set of tradeoffs here, and other browsers are increasingly encountering the same tradeoffs as they grow their marketshare."

    I don’t doubt it, as most of it is dealing with old IE versions behavior that was in conflict with standard, loosely standard or outright bugs persisting for many years. When you competition decide they would focus on stricter standards around a decade ago. Have you ever noticed the difference between modifying sites when new versions release of IE 5 -> 6 -> 7 -> 8 vs any modern browser’s previous version in the past 5 to 10 years. It is generally a pain in IE and rarely ever any problem in others.

    Don’t get me wrong, I like the direction you seem to be going now and I have been following for a quite some time, but IE9 looks to at best be what I was hoping you would have been at in version 8 instead of being out 2011-ish.

  52. hAl says:

    @EricLAw

    You claim "Mozilla and Compatible strings need to consider the point made by Rob and Matt– doing so will cause significant problems for a significant number of sites."

    I do not believe this claim without more info on what you consider significant.

    Also it is very unlikely that thew few sites that do scan for this string delivier content suitible for IE9 based on these strings. They are likely to produce IE6 compatible code which we do not want when using IE9.

    IE9 should rather get standard compatible website than a IE6 specific content which is much more likely to happen on a site still scanning for those strings.

    As it stands I consider it a big mistake.

    If needed we (the IE9 testusers) will convince any remaining site owners, that scan on these strings, that they need to chance their sites and that even before a final release of the browser.

  53. Matt says:

    @hAl: First, you can complain to WellsFargo; they block users of the proposed UA. Then you can complain to TurboTax online; they block users of the proposed UA. Then you can go complain to the several thousand other sites I didn’t bother to try. Glad to help keep you busy.

  54. > Would you mind pointing me to any data you’ve collected on the topic? I’m always interested in learning more.

    Eric, I have already given IE team and your corporation a lot of time.

    On user agent string detection, I have already listed the relevant posts in this IE Blog. When "Clue" says

    > Go read the comments on every past post on the user-agent string; we’ve all been here before, (…)

    then I know he is correct, factually correct and telling the truth.

    I would start with MAMA study, Google

    december 2005 Web Authoring Statistics study (based on a billion of webpages), articles on browser sniffing, etc.

    Your company disposes of a lot of resources, time, people, etc.

    > Yes, it’s true that the IE team invests more in compatibility than many other browsers do.

    I already answered this many times already.

    @Marc Silbey [MSFT]

    "Mozilla" is not the appName; it’s the appCodeName.

    Gérard Talbot

  55. Brianary says:

    @Matt: Please clarify "block"; do they prevent or simply discourage use?

  56. Matt says:

    Gerard, let me get this straight– you’re willing to assert a position but not willing to provide any data, and instead complain that you’ve already given a lot of time? Why bother complaining here at all, if you value your time too much to actually support your arguments?

    Brianary, for most users, a confusing or nagging suggestion is no different than an outright block.  

    But, in both of these cases, it’s an outright block:

    "Wells Fargo does not support the browser version you are using. Please switch to a supported browser in order to get access to our secure sites."

    "To ensure you have the best possible experience using TurboTax Online, your computer must meet the following system requirements."

  57. Brianary says:

    @Matt: I don’t think so. IIRC, I’ve used TurboTax with a modified UA. I believe it’s a suggestion, despite the abusive language. But point taken for many (if not "most") users.

    Either way, for reasons I’ve gone into (see above), it’s an astoundingly stupid practice. A quick link, emailed from a Microsoft address, to an explanation of why modern feature-testing is superior to UA sniffing would help. Again, not primarily for this issue, but because UA sniffing is so fragile, exclusionary, and temporary.

  58. Mitch 74 says:

    @Matt: that’s what Compatible (like IE 7) mode is about. No, really! Why go to the trouble of programming a complete emulation layer for an older browser, if you still keep ‘oldie’ features on the new one? You have the unique opportunity for a clean cut! Dang, just do it!

    When us developers pissed and moaned about IE 8 not defaulting to its best mode, you reluctantly agreed; the solution you put in place was costly, yet efficient, and applying this one here would just cash back on it, end of story:

    – website refuses IE9: listed in the Compatibility list, defaults to IE7 mode, with ‘Mozilla/4.0’ UA string, problem solved!

    – website accepts IE9, will accept ‘Trident/5.0’ UA string.

    What has you worried? That, for some reason, a website programmed to standards would refuse IE 9 if it didn’t start with ‘Mozilla’? Well, it’d turn Opera back, too.

    Keeping ‘Mozilla/4’ for IE 8 was understandable: Trident 4.0 was not good enough yet to really enter the ‘standards browsers’ club. That ain’t true with IE 9.

  59. Matt says:

    >I believe it’s a suggestion, despite the abusive language

    Wrong. Anyone can do this right now and clearly see that you’re incorrect. There is no "ignore and continue" or anything like that.

    I don’t think anyone thinks UA-detection is a good practice, but the idea that web developers just drop everything when they get an email from @microsoft.com is profoundly naive.

    > that’s what Compatible (like IE 7) mode is about

    Emulations are determined *after* the User-Agent header is already sent.

    Compatibility tradeoffs are all about cost/benefit, and the cost here is high, and the benefit is low. The OP already announced what IE9 will do, so all of the comments here are just that… commentary.

  60. Gyrobo says:

    @EricLaw

    Thank you very much for your response.

  61. Brianary says:

    @Matt:

    "Wrong."

    Perhaps. It’s possible I used User-Agent Switcher to continue.

    "…the idea that web developers just drop everything when they get an email from @microsoft.com is profoundly naive."

    First, I’m not suggesting that anyone is going to "drop everything". What I’m saying is it’s a little harder to completely ignore the company that makes the software most of your customers are using to access your product. It’s another voice for best practices.

    Second, have you tried it? This sort of mopey nihilism is why we’re out here trying to get people off of IE6 without any backup from Microsoft. Why would any business change? Microsoft is going to support IE6 until 2014!

    Is "Mozilla" the end of the world, or even in my top 10 suggestions for IE right now? No. But commentary was solicited, so here it is.

  62. George Wurst says:

    How about adopting Opera’s idea and extending the compatibility list for these purposes?

  63. Brianary says:

    @Matt:

    Also, TurboTax’s response depends on the UA. In Chrome (WebKit, like Safari, which *is* supported) I get:

    "Please make sure your computer meets the TurboTax Online system requirements.

    To ensure you have the best possible experience using TurboTax Online, we recommend that your computer meet the following system requirements.

    If you continue without upgrading, we may not be able to assist you with any issues you might encounter.

    [Continue]"

    With Opera:

    "Please make sure your computer meets the TurboTax Online system requirements.

    To ensure you have the best possible experience using TurboTax Online, your computer must meet the following system requirements."

    I’d imagine that, were Microsoft to adopt the suggested UA, Intuit might just figure out how to add another item to their greylist.

  64. Matt says:

    no one is saying that websites would be unable to change to support a different UA format.

    the point being made is that M$’s proposal breaks fewer sites than the alternatives, and there seems to be a lot of agreement that creating an entirely new UA value isn’t all that important in the grand scheme of things.

  65. wechrome says:

    UA strings should be dropped entirely, or just make them as short as possible, something like IE9, FX3.6, GC4.1, Safar4, Opera10.5. It’s not just an IE problem, it’s a problem of ALL browsers out there, and no site should try detecting browsers based on such unreliable info, which can be arbitrarily changed to any random things. I can easily change my UA string to "hellokitty" within seconds.

    Really, everyone browser out there, including IE, Firefox, Chrome, Safari, Opera, etc. etc. should just drop this ridiculous UA string thing, and if a site wants to do browser sniffing, it should do it in better ways.

  66. gabe says:

    id love for the ie team to list what version of trident each version of ie uses what version of trident did ie4 use or ie5 or ie6 etc

  67. Klimax says:

    At gabe:

    Was already answered. (In earlier comment!) Prior to IE8 there was no versioning of trident.

    ===

    Wednesday, March 24, 2010 9:11 AM by EricLaw [MSFT]:

    "@Gyrobo: No, there wasn’t a public versioning scheme for Trident prior to IE8. While MSHTML.DLL had a version number, it had no particular meaning. For IE8, Trident was declared to be 4.0, and now for IE9, Trident is declared to be 5.0."

  68. hAl says:

    @Matt

    I am not interested in altering the behaviour of sites sites that are blocking the proposed UA.

    Those sites just support our claims that this news UA is rubbish and does not really do anyhting valuable for compatiblity.

    It shows that many sites will have to change their behaviour with this proposed UA.

    Changing it in such a way that that the mozilla en compatible strings are removed would not likely mean significantly more sites that have to change their behaviour.

  69. Mitch 74 says:

    @Matt: Compatibility mode is determined after the headers are sent: I’d say you’re right, except in 3 cases:

    – the domain name is listed in the Compatibility list published by Microsoft.

    – the domain name has been listed as a ‘compatibility’ site on a user’s local list.

    – the user clicked on ‘compatibility’ icon and hit F5.

    In these 3 cases, headers sent match IE7’s. And that solves the UA detection problem.

    Hey, it was enough of a hassle for the IE team to solve for IE 8, let’s cash up on it on IE 9!

  70. Chris says:

    hi,guys, have you had any improvement of developer tools? the performance of it in IE 8… even worse than the former one.

  71. EricLaw [MSFT] says:

    @Chris, you can see the improved developer tools in the Developer Preview Build. Major performance improvements have been made already.

  72. Brianary says:

    Interesting, TurboTax now supports "Trident/5.0 (MSIE 9.0; Windows NT 6.0)". That was fast.

  73. Brianary says:

    @wechrome:

    User agents are still useful in aggregate for logging purposes, so you can watch for tipping points on new feature support, like HTML5.

    They should just never be used on an individual level to filter access or  content.

  74. Brianary says:

    What I’m really curious to see is what the UI for the user to switch between the four rendering engines looks like.

    I assume IE6 (quirks) mode still doesn’t get it’s own button, but is activated when the first content isn’t a doctype, and/or if the X-UA-Compatible header/http-equiv meta tag is set to IE=EmulateIE7.

    I assume there will still be a "broken page" icon to trigger IE7 (document.compatMode==’CSS1Compat’) mode, and that X-UA-Compatible set to IE=7 will also trigger this mode.

    I further assume IE8 mode can be activated by an X-UA-Compatible of IE=8.

    What is less clear is how IE8 mode will be triggered by the user. Will there be a "page discouraged", "page is disappointed", "page dented", "page contents may have settled during shipping", or "melancholy page" icon?

    Will there be a way to switch back to IE9 mode: a "page is slightly more awesome", "page feels held back", "page cleans up real good", "page wants to change out of its sweatpants", or "page yearns" button?

    It’d almost be worthwhile to complete the set with the IE6 button: "page on fire", "page savagely beaten", "page dragged behind truck", "page will never, ever drink again", or "damned page".

    Just some idle speculation.

  75. Stifu says:

    @Brianary:

    "I assume IE6 (quirks) mode (…)"

    IE6 mode isn’t the same as quirks mode, and no IE version other than 6 has an IE6 mode. Quirks mode is a slight variant of the IE5.5 rendering.

  76. Brianary says:

    @Stifu:

    That makes keeping quirks mode around just that much more awesome؟

  77. the goggles do nothing says:

    @Joe Marini – wow! that’s an Epic Fail of a userAgent string!

    Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0) <DeviceManufacturer>;<DeviceModel>

    So, MSFT’s brand new iPhone competitor is shipping with an MSIE7.0 browser?

    No wait! its shipping with a Trident/3.1 browser! (gah! 1998 wants their quirks rendering back!)

    Can someone please explain in IE terms what this actually means (no BS marketing garbage).

    What rendering level are we getting or forking from?

    IE5, IE5.5, IE6 or IE7?

    Or is MSFT just expecting every developer to roll over and start hosting Silverlight only applications because Mobile IE can’t render the modern web?

  78. EricLaw [MSFT] says:

    @goggles: Per the Phone team, Windows Mobile 7 will ship with an engine that is "halfway between IE7 and IE8 rendering engine."

    http://news.cnet.com/8301-13860_3-10452710-56.html

    For further discussion, you’ll want to see the Windows Mobile team blog.

  79. Wurst says:

    @Brianary: Quirks mode is IE 5.5, not IE 6

  80. Brianary says:

    I love that people are correcting my comment in which I’ve proposed "melancholy page" and "page will never, ever drink again" buttons.

    It’s important that satire be accurate, I guess. ☺

  81. future IE9 user says:

    Has someone noticed a funny thing?

    After installed the registry fix, see what happens at IE 8. It will identify itself as IE 9, with the new User Agent.

    Can someone explain this behaviour? Is it due to common settings between IE 8 and 9?

  82. EricLaw [MSFT] says:

    @future: Yes, the registry script will change the UA string sent by any version of IE you have on your system.

    For folks looking for the "undo" script, it’s here:

    http://www.enhanceie.com/dl/UA_UNDO.reg

  83. Kindermode says:

    @hAl I like your idea… but MSIE is always a bit different :D. But I am happy to see IE in Version 9 hope some things are more like in Firefox and safari. I love the commercials in Germany but I think they miss the people they should hit!

  84. future IE9 user says:

    @ EricLaw Ok, so it is common for any version of IE side by side with 9 Technical Preview. Well, as long as it doesn’t cause me problems, I can keep the new UA. Thanks for the answer!

  85. wechrome says:

    @Brianary,

    “User agents are still useful in aggregate for logging purposes”

    That’s exactly why it should be as short as possible, things like IE9, FX3.6, Opera10.5, etc. etc. should be more than sufficient already. Why do we need to waste our bandwidth with “Mozilla/5.0 Gecko/20100316” in Firefox, “Mozilla/5.0 (KHTML, like Gecko)” in Chrome, etc.

    Like I said, all browsers should seriously trim their UAs already, it’s not just a problem for IE, everyone out there should at least drop the useless Mozilla/x.x first, and few needs to know what engine version the browser uses, just the browser version should suffice already.

  86. Randal says:

    I agree 100% that developers should not be doing user agent sniffing for any purpose – however there are times when doing so seems to just make sense.

    For example you need to support IE6+, Opera 8+ and you want to be able to use document.getElementById correctly (as per the specs)

    Before IE8[standards mode] and Opera9.5 this method was broken in both of these browsers.

    http://webbugtrack.blogspot.com/2007/08/bug-152-getelementbyid-returns.html

    IE broke it first and then Opera broke their implementation just to handle sites to maintain compatibility with sites that used IE’s broken implementation.

    If it was only IE that broke it we could add a conditional comment wrapping a script include that targeted IE7 and below and be done – but since Opera broke too we can’t do that.

    We could test for the existence of the method, but that would be pointless since both will claim to support it.

    We could build a function that creates a temp element with a specific ID and then try to fetch it with a different case ID – AND – create a temp form element with a specific NAME and try to fetch it with getElementById.

    However both of those tests penalize the users of browsers that built the methods according to the specs by running unnecessary code just to fix IE & Opera bugs.

    Thus as a result – rather than force all browsers to process code to fix these kind of bugs developers check the user agent string for key indicators to see if a browser is IE or Opera or X.

    //pseudo code

    if(msie || opera){

     //run test to see if this version has the bug

    }

    Does this kind of code make my skin crawl? you bet it does! However I have to be realistic about this.  I don’t want every single page in my applications and websites to have to run massive tests to see if a feature is implemented correctly.

    Therefore I do a quick check to see if the browser is reporting itself as IE or Opera or X and then *IF* that browser is known to have had an issue with a certain method I will test to see if the implementation is missing/broken.

    Do I run the risk that a Firefox user might be sending a Safari user agent string? you bet (very low risk)

    Do I ensure that my code is future proof? of course! (browsers may drop "compatible" or "mozilla" from their user agent strings one day but IE will never drop "MSIE" nor opera drop "Opera" – and even if they do, I only have 1 test to update in my apps, not 100’s of occurrences.

    I’ve personally taken my code beyond this too.  I run basic checks when the user logs in to my applications, then store browser details in the session.

    When the user hits page 2 through N, I don’t need to re-run the tests, and my server only pushes script/css content to the browser that it actually needs.

    e.g. Once I know that a user is on IE6, I push all the hacks/fixes it needs – if they are on Firefox or Safari I only need to push the core JS/CSS

  87. oliver says:

    Just thought I’d share this gem!

    Want to know if you are in IE in JavaScript in a real easy way?

    <script>

     var ie = /*@cc_on!@*/false;

    </script>

    Will set ie=false for all browsers except IE.

    Or if you are really into terse code:

    <script>

     var ie = !+[1,];

    </script>

    For the curious, the first works because IE supports conditional compilation comments in script thus the "!" only applies to IE.

    The second works because only IE fails to handle array initialization with a trailing comma.

  88. @Oliver: Thanks for the example that demonstrates why it’s dangerous to rely upon tricks like this.

    You’ll find that your latter example returns "false" in IE9 Standards mode.

  89. stan says:

    @EricLaw – returns "true" for me in the IE9 platform preview.

    But you are right, these shouldn’t be used to test for IE and then provide hacks – however since IE9 fixes most of the things that developers are creating workarounds for it is likely a moot point since the "fix" won’t be applied to IE9 – but it won’t need it either! 😉

    I agree with Randal – providing optimized fixes for IE6, IE7 & IE8 is a great way to handle IE issues while still allowing for good browsers to not load additional content.  Over time I’m sure that this will all be obsolete once IE7 is no longer used.

  90. EricLaw [MSFT] says:

    @stan: Did you put your test page in IE9 Standards Mode? Even in the IE9 Preview, a Quirks mode page will return "TRUE".

  91. Harry M says:

    @Will Peavy – unless we all miss-read EricLaw [MSFT]’s comment, the IE9 user agent string will **NOT** be shortened.

    "Wednesday, March 24, 2010 7:19 AM by EricLaw [MSFT]

    @Gary, zzz: As Marc outlined in his post, none of the .NET identifiers or other "post platform tokens" will be sent to the server in the IE user-agent."

    Thus all the .NET crud that is currently in the IE user agent string will still be there (and will likely only get worse over time)

    I do however agree that **ALL** extra fluff added to the user agent string should be REMOVED and BANNED.

  92. EricLaw [MSFT] says:

    @HarryM: Yes, I believe you misread my remark.

    Saying again: **none** of the .NET identifiers or other "post platform tokens" will be sent to the server

    This means that the article that Will cites is correct in noting that the new IE9 behavior will significantly improve shared proxy caching.

Skip to main content