Seems like about half the issues you've mentioned relate to differences in syntax/behaviour. This is to be expected. That is what vendor prefixes are for. They are a known (and necessary) evil. Would you prefer to allow the design by committee approach to continue? We've already suffered through 10 years of stagnation due to this approach.
Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next.
This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine).
Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next.
On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully.
Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets.
Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder.
The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on.
If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.
Seems like about half the issues you've mentioned relate to differences in syntax/behaviour.
If you mean the bugs I described, then no, I think all of them are genuine bugs.
There's no way to justify Chrome not redoing page layout or repainting properly after a DOM or CSS update. That's just sloppy, and it's a serious problem if you're writing app-style pages. Unfortunately, I don't have a self-contained, reproducible test case: we see this a lot using toolkits like jQuery UI when showing (or not) dialog boxes, but unfortunately it's a bit of a Heisenbug, or possibly several Heisenbugs. The general issue has been reported somewhat widely in Chrome-related blogs, though, and IIRC there were some issues already in their bug tracker that looked like they might be related. The latter led to some blog posts suggesting workarounds with JavaScript that might correct the CSS calculation errors in at least some of the cases. The issue has been there for several months, and still hits us from time to time.
The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners horribly ugly and which seemed to take several attempts to finally get right. (Of course there were browser prefixes and so on in this area as well for a time, but that's not what I was referring to.)
The H.264 issue is just a mess. The fact is that Chrome supported it, and then Google said after a future update they wouldn't support it any more. They were planning to push an update that outright removed functionality, and that functionality was in one of the few cutting edge areas that was really taking off at the time, too.
And Firefox screwing up support for the plug-ins was just poor quality checking before a release. There's no excuse for breaking something on that kind of scale, particularly when the bug was already in the tracker several days before the update was pushed out.
Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.
No, they really don't. When my clients ask why the software they've paid me a lot of money to write for them has stopped working, with the result that their on-call guys are getting woken up in the middle of the night by someone on the far side of the world who can't use their very expensive equipment any more, the answer they are looking for is not "Well, you see, we use a Java applet in this product because when we started the project a few years ago HTML5 canvas didn't have the functionality, speed or portability we needed, and that Java applet requires that the user have a Java runtime installed on their system and a corresponding plug-in for their browser, and your customers are using Firefox as their browser, and Firefox pushes automatic updates, which in a stunning piece of incompetence your customers' system administrators have not disabled, so their key systems will apply the updates before anyone tests that nothing important breaks, and in one of those updates the Firefox developers kinda broke a bunch of things on pages that use applets, and that's why the users can't type text where they should be able to, and so it's really not our fault, but at least these bugs will probably get fixed in the next release and that probably won't be more than six weeks away, so for now your platinum support guys should tell your customers to just hang in there for some unknown length of time and then they'll be able to use that very expensive hardware again, and in any case I'm sure this won't in any way jeopardize that contract you were going to get to sell them another 250 units in a multi-million dollar deal next month." No, trust me, that's really not what paying clients want to hear at all.
It's a shame you don't have a reproducible test for the rendering issue in Chrome. Until you can reproduce it there's really no telling what is going on. Do you have any links to similar issues already reported? I'd be curious to read up on them.
The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners
Any test cases for this? It really is important to see a simple test case. I've never had any issues with either Chrome or FF with corners.
Sure h.264 is a mess. If it bothers you then don't use it. The fact is that Flash is still defacto standard for video, so for consumer facing pages that's probably what you should use.
Sounds like you're upset because you got burned by a recent issues with firefox. It's reasonable to expect such a big breaking change to be caught in their regression testing. Unfortunately it slipped through. The reality is that software has bugs. All software. Yours, and mine. Every product ever shipped has gone out the door with bugs. It's unpleasant, especially when you have no control over the fix.
Seems to me that a rapid release cycle actually works in your favour. Certainly better than the MS cycle where you can expect to have to live with bugs for 18month-2years between releases. Auto updating in particular is a boon for developers. If you look at the Chrome version stats, most people are on the latest stable build and this is mostly due to auto update.
Also, if you're developing an app which is actually used for 'multimillion $ deals' then why aren't you distributing it as an application inside of some kind of wrapper such as Qt? Sounds like deploying as a regular web app was a bad technical choice for you product.
As far as video goes, Flash is not the de facto standard any more if you're working with mobile. Apple won that one. And H.264 is technically superior to the other useful formats for HTML5 video and the only format supported and/or supported with hardware acceleration on several platforms, so dropping it isn't much of an option.
Finally, on the subject of testing, it wasn't really me personally who got burned by the Firefox screw-up, it was one of my clients. Their technical people understand that there isn't much I can do about it, but that doesn't help their customer support people who have to deal with irate customers.
In any case, we actually recommend that their customers use IE rather than Firefox or Chrome these days, because for all its sins, it is a stable platform to build on and we can test against it with some confidence that end users will see similar behaviour for a useful period of time to come. No-one connected with this project likes rapid browser release cycles: not the developers, not the users, and certainly not the guys paying my invoices, who are on the wrong side of both.
Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next.
This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine).
Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next.
On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully.
Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets.
Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder.
The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on.
If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.