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:
- 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.
- Version token is incremented from ‘MSIE 8.0’ to ‘MSIE 9.0’.
- Trident token is incremented from ‘Trident/4.0’ to ‘Trident/5.0’.
- IE9 will send the following short UA string without additions made by other software installed on the machine:

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
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.
@Clue:
Touché. What a well-reasoned and cogent argument against… something. Or maybe in favor of nihilism?
**slow clap**
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)
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)
@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.
@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.
> I do not believe this claim
> I consider it a big mistake
so what, WTFAY?
Will an "IE8 View" be available for developers, and if so what will the UA string be?
Please do away with the Mozilla token, its legacy, many wanted to see it gone in IE 8, please get rid of it.
@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…
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.
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.
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.
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.
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.
@Marc Silbey – thanks for the .reg file.
UA sniffing is being used at: http://browserscope.org/
@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.
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/
Wow. FOUR rendering engines‽ Just… wow.
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!
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.
Hi, Why trident token is in comment?
and wander about next IE9, his user agent contains "MSIE 10.0"?
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.
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.
@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…
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…
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.
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.
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?
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.
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.
It’s not only this DirectX 9, e.g. Windows XP and IE8.0 have no prodect mode.
@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.
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!
@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.
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/
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!"
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.
@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)
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?
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.
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.
@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.
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"?
@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.
@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
<<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.
@EricLaw [MSFT] Can we please get a list of those sites so we can start visiting them with Opera every five minutes? 😀
@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.
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
@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.
@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.
@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.
> 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
@Matt: Please clarify "block"; do they prevent or simply discourage use?
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."
@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.
@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.
>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.
@EricLaw
Thank you very much for your response.
@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.
How about adopting Opera’s idea and extending the compatibility list for these purposes?
@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.
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.
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.
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
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."
@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.
@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!
hi,guys, have you had any improvement of developer tools? the performance of it in IE 8… even worse than the former one.
@Chris, you can see the improved developer tools in the Developer Preview Build. Major performance improvements have been made already.
Interesting, TurboTax now supports "Trident/5.0 (MSIE 9.0; Windows NT 6.0)". That was fast.
@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.
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.
@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.
@Stifu:
That makes keeping quirks mode around just that much more awesome؟
The Windows Phone team has posted their User Agent string for IE Mobile too:
http://blogs.msdn.com/iemobile/archive/2010/03/25/ladies-and-gentlemen-please-welcome-the-ie-mobile-user-agent-string.aspx
@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?
@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.
@Brianary: Quirks mode is IE 5.5, not IE 6
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. ☺
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?
@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
@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!
@ 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!
@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.
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
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.
@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.
@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.
@stan: Did you put your test page in IE9 Standards Mode? Even in the IE9 Preview, a Quirks mode page will return "TRUE".
http://zoompf.com/blog/2010/03/the-big-performance-improvement-in-ie9-no-one-is-talking-about
@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.
@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.