Without wishing to piggy back on this thread I feel its a good time to point out that this is exactly why enterprises stick with IE. People are risk averse in businesses.
That's funny, where I work (yes it's Enterprise scale) it is far more likely the tools work in Firefox than recent IE, Safari or Chrome.
Closer to the truth is that Enterprise's stick with whatever it was that their developers were using when they developed the tool. That just happened to be Netscape/Mozilla browsers when some of these tools were written where I work.
I thought that had more to do with the billions of dollars invested in IE-only web applications and the astronomical cost of upgrading, retraining and supporting thousands of people, not the fear that one version of Chrome will someday break CSS behavior.
No not at all. Most of the LOB applications you see these days work very well in most browsers. Ours works in Firefox, Chrome, IE, Safari perfectly and is entirely plugin free. I've not seen an ActiveX for about 5 years and that was a file upload control. All our fugly desktop integration is done with a broker application which runs on the user's machine and talks to local COM objects via web services. You see an occasional fugy J2EE page or a WebForms page but mostly, it's pretty spankingly good looking and works well. This is financial sector stuff as well which is the worst market for heel-dragging.
Corporations fear things breaking. Retraining is rarely an issue for a browser upgrade. However, if someone pushes out a crap Chrome update like this and an LOB application goes pop then heads roll. Chrome is entirely out of band from their normal operations and skill sets so it just doesn't even get considered. It also has dubious unpredictable support lifecycles and a rate of change which would scare anyone. To use a car analogy: they want a 3 year old Volvo, not a 6 month old Tesla.
I think being able to differentiate in the browser market is a great thing. Chrome can offer tools for enterprise use, but I seriously doubt that they are ever going to offer long term support for old versions. Meanwhile that's Microsoft's bread and butter, but that means that if you want a larger portion of experimental or recently finalized web features, you have to go somewhere besides IE.
What's bad is when you have to cater to old, broken IE behavior because you have to support that part of the market. We're seeing much less of that and more just "IE doesn't support new feature X". That does hold back some of the newest stuff, but not having typed arrays is not at all comparable to having to support IE6, for instance.
Personally, I would be ecstatic if we can maintain for as long as possible this nearly even split of marketshare over three (desktop) browsers.
I've been working with some large enterprises in the past (50k+ employees), all of them only use IE and all of them are full with some crappy ActiveX software, some by HP, some homegrown, it's really full of that crap. :(
Even software that would support multi-platform is crippled in a way that only Windows+IE works, because in the projects noone cares if some other browser or (god forbid) another OS is supported.
In my experience those kind of companies are heavily involved with big players like MS, HP, etc. who all push their own proprietary crap. Bundle this with a "we don't allow employees to install other browers so why should we care/test/develop for other technologies? We can even assume every PC has ActiveX installed and ready, so hell yeah let's use that!"
You'd be surprised. The amount of CSS/HTML that goes into your typical LOB application is quite large and the applications are typically orders of magnitude more complicated than "sites" as you mention. The piece of kit I work with has approximately 900 ASP.Net MVC views...
I just ran CLOC. We have 6.2 million lines of code in 14 different languages!
It's orders of magnitude more complicated, and generally for no good reason. There are often conflicting CSS rules, or 100 lines of cruft when 10 lines might work just fine.
And yes, things break all the time, often for unknown or unexpected reasons, and it's sometimes close to impossible to figure out why and fix the bug.
As someone who worked on an internal NHS website I can affirm this. Rather than use the same CSS and HTML for a form no matter which page it appeared on, the original coders had re-written it from scratch every single time, with slight differences (some intentional, some bugs) between them all.
Oh, and the entire site didn't work in IE6, it was developed / tested entirely targeting Firefox, despite the IE6 requirement being in the spec (and it ONLY needing to work with IE6).
Some of the most advanced CSS and Javascript I have seen for the first time in Enterprise apps. I first saw xmlhttprequest in a Cognos controller, I first saw drag+drop in a browser in another enterprise app.
the Outlook web interface was miles ahead of anything in the consumer space for years.
Indeed. We basically wrote our own version of jQuery, backbone.js and a whole functional toolkit with 150 functions and 30 client side controls and a validation framework about 5 years ago and it even worked on IE 5.5...
Closer to the truth is that Enterprise's stick with whatever it was that their developers were using when they developed the tool. That just happened to be Netscape/Mozilla browsers when some of these tools were written where I work.