As an example. Run something like Test 262(http://test262.ecmascript.org/) which is the official test suite for JavaScript 5 and you'll see how many compatibilitiy issues there are just for this single spec in Firefox. It's in the hundreds.
Anyone of these could potentially break an app. And that is just for one of the many specs in Firefox.
Your problem there is really with the standard...
But more importantly, intranet apps are not coded to standards to start with, so the whole discussion is moot.
Your argument about Intranet apps not coded to standards seems circular. If browsers (like Firefox) don't implement the standards properly, then how can Intranet apps code to standards? It has to start with browsers.
Yep. Support for all the new ES5 features... Doesn't guarantee that it's all bug-free, sadly. That said, you may be interested in the graph shown in http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-indust... (ignoring for the moment the "start at 50%" inanity).
You may also be interested to note that changes continue to be made to the ES5 specification; the most recent ones happened just a few months ago. The whole moving target thing makes it hard to comply with all the edge cases at all times, obviously. I would not be surprised if there are now test262 tests that are testing the old language, and will need to be fixed just like browsers will need to be fixed.
> Your argument about Intranet apps not coded to standards > seems circular.
I wasn't making an argument; just stating a fact.
But note that the non-standard assumptions that intranet apps make are not even in the sort of things that 262test shows as broken in browsers: the latter tend to be somewhat esoteric due to the obvious fact that browsers sort of agree on the JS used on the web. But intranet apps tend to be coded to particular DOM quirks (in areas where the standard often doesn't define behavior to start with), particular HTML parsing quirks (until recently there was no standard for parsing HTML), and so forth.
Or put another way, intranet apps have a tendency to find situations where there is no behavior defined by a standard and depend on behavior in those situations, when the smart thing to do would be to avoid those situations entirely.
It's worse in most cases as there aren't fully built out tests, so it's even more difficult to converge implementations to the specifications.