Slashdot Mirror
Firefox: In With the New, Out With the Compatibility
snydeq writes "Mozilla's 'endless parade' of Firefox updates adds no visible benefit to users but breaks common functions, as numerous add-ons, including the popular open source TinyMCE editor, continually suffer compatibility issues, thanks to Firefox's newly adopted auto-update cycle, writes InfoWorld's Galen Gruman. 'Firefox is a Web browser, and by its very nature the Web is a heterogeneous, uncontrolled collection of resources. Expecting every website that uses TinyMCE to update it whenever an incremental rev comes out is silly and unrealistic, and certainly not just because Mozilla decided compatibility in its parade of new Firefox releases was everyone else's problem. The Web must handle such variablility — especially the browsers used to access it.'"
Use the ESR version and don't stress about major version changes until November-ish.
Maybe TinyMCE isn't actually as "platform independent" and "cross-platform" as it claims?
Code to standards (with appropriate polyfills) and ye shall prosper.
Tons of websites, including those with advanced features work perfectly with updated versions of firefox.
So what's wrong with this particular feature? And why is it that FF is getting the blame?
The real annoyance for me is the version numbering / compatibility scheme. There are add-ins that are still relevant, and still work perfectly, but you have to go through a song and dance to install them every time the version numbers change, the song and dance being unpacking them, editing the version numbers in their metadata, and repacking them, or finding the add-in in your profile from an older version and editing it there.
If they could fix this, that would be much better. Instead of add-ins declaring which versions they are compatible with, it should be possible to compute which APIs they access, and whether their behaviour has changed.
In the case of TinyMCE, I'm not sure what the issue is, unless people are packaging it as an add-in - my only encounters with it are as something embedded in a web page, so it would naturally have to cope with a wide variety of browsers by default.
You mean like Chrome's rapid release cycle?
Mozilla is actually changing to an "assume it works" model where addons will be enabled and version compatibility information will be ignored, since most addons will still work fine. They might only enforce it for major updates or something. So you won't have to do this for much longer.
None of the extensions I use break with 'every' revision. Most I don't even think have needed to be upgraded from 8.0 to the current 13.0a2[Aurora], and it updates Firefox essentially every time I restart Firefox. It makes me think TinyMCE are the one's doing something wrong.
TinyMCE is not an addon - the article seems to be talking about a Firefox bug, but doesn't provide a bug ID.
Addons are now up-issued automatically where possible; I have found fewer addons breaking compared with the sweeping changes made using the old model of major releases.
The article also misses the benefits from regular releases: features and improvements get in front of users more quickly, and changes are incremental, rather than jarringly abrupt. See http://en.wikipedia.org/wiki/History_of_Firefox_(Rapid_release_development_cycle) for a list of changes since Firefox 4.
This is so obvious, I feel like I'm taking crazy pills.
Users see the Firefox version. Plugin developers see the plugin API version. So if FF 10, 11, 12 ,13 all have the same API, then they are automatically compatible. New features added to the browser can be tested for. Removing features causes a API rev.
ffs, just do it and stop with all the noise!
-d
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
They're not whining over a numbering scheme, they're whining over a plugin compatibility scheme.
Go green: turn off your refrigerator.
a) Chrome have always done it that way.
b) Chrome doesn't fucking break everything every upgrade!
Honestly. Does Firefox still give you a XUL error instead of sensible HTTP error pages if it's upgraded and you haven't restarted it yet?
The only reason there would be a compatibility problem is if programs/scripts/modules/whatever are using user-agent identification to determine what features are available. This is (and always has been) a very bad practice - You check to see if the functions (or alternatives) are available, rather than checking against UA. That way you don't have to continually update scripts to maintain compatibility with the latest versions. When when browsers start supporting new functions coded in, those functions just work. When deprecated functionality is removed, the check for that particular function fails and the code moves on to another branch.
For example, rather than the following:
function getXMLHTTP() {
if (navigator.appName == 'Microsoft Internet Explorer')
{
var ua = navigator.userAgent;
var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
if (re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
if (rv try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
catch (e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) {}
} else
return XMLHTTPRequest;
} else
return XMLHTTPRequest;
}
Which uses nasty browser detection to try and cope with IE 8 and below, you should use:
function getXMLHTTP() {
if (XMLHTTPRequest) return XMLHTTPRequest;
if (ActiveXObject) {
try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
catch (e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) {}
}
throw new Error("This browser does not support XMLHttpRequest.");
}
Which nicely checks to see both if the newer/proper XMLHTTPRequest Javascript object exists, and if not, tries to use the latest ActiveX object (Necessary for IE 8 and below), while only using the "ActiveXObject" function if it is available. It also means that if MS put out a version of IE that falls back to the ActiveX Object route, this code will still work with it, whereas the first will not. It's a minor example, true, but it's an example nonetheless.
Is this something people actually use?
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Some pointless comparisons.
Numbers below are rounded off, does not include beta versions (including pre-1.0). Also, my math is probably off.
Internet Explorer - Averages new version every 21 months
First Version: IE1 - August 1995
Current Version: IE9 - March 2011
Firefox - Averages new version every 9 months (every 1.7 months since version 4.0)
First Version: Fx1 - November 2004
Latest Version: Fx11 - March 2012
Chrome - Averages new version every 2.2 months
First Version: Chrome 1 - December 2008
Latest Version - Chrome 18 - March 2012
Opera - Averages new version every 17.5 months
First Version: Opera 2 - April 1996
Latest Version - Opera 11 - December 2010
Safari - Averages new version every 18 months
First Version: Safari 1 - January 2003
Latest Version: Safari 5 - June 2010
Lynx - Averages new version every year or so
First Version: Lynx 1 - sometime in 1992
Current Version: Lynx 2 - sometime in 1993
I threw Lynx (actually currently on 2.8, June 2010) on there because it's proof version numbers mean nothing anymore.
b) Chrome doesn't fucking break everything every upgrade!
I have to agree with this. Despite Chrome's background updates, I haven't woken up and launched it to find half of my plugins are dead. Nor have I had to turn compatibility check off or any of the other coaxing I've needed to do to get my FF plugins working.
I've been told in the past that a large part of the compatibility breaking is due to add-on developers, not Firefox itself (something about writing the add-on to ignore a version incompatibility), but either way, the net result is the same.
Admittedly, I can't speak as to the last couple years or so, because starting at Firefox 4, the combination of Flash, two ATI video cards in crossfire, and Firefox has resulted in regular, yet completely unpredictable BSoD's, and everyone I've ever talked to in support has pointed to a fault with one of the other two parties and said there's nothing they can do. Upgrading to 5 didn't help, and upgrading to 6 didn't help as well. That's when I uninstalled Firefox for good. Chrome has never done that, even with Flash, and even with hardware acceleration turned on.
Now that Chrome has AdBlock Plus and ScriptNO and all of the other plugin equivalents I care about, I no longer pine for Firefox.
I hate this rapid-release fad. The downsides far outweigh the upsides for me.
Solution: http://www.debian.org/releases/stable/
Spoon not. Fork, or fork not. There is no spoon.
puts an unbelievable amount of tentacles into your system
Citation?
I've seen no evidence (nor even claims, before yours) of this.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
The thing is, I don't care. In fact I prefer my browser not to muck about with user-facing stuff all the damn time. I used Firefox again recently for a few minutes and the disappearing/reappearing forward button was both maddening and utterly inexplicable.
Maybe Add-on writers should push it up a few versions and hope it works? I dunno.
Mozilla forbids Add-on writers from putting it more than 2 major version numbers ahead. This policy worked fine when 2 major version numbers took years... but right now, that's 12 weeks.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
people bitched that there add-ons were getting disabled for no reason due to version compatibility checking, so they removed it. Now people are bitching that there add-ons are breaking?! How it this mozilla's fault? you got what you wanted! It is the add-on developers responsibility to either enable compatibility checking, or test there add-on before each new version.
besides, why would you even need an add-on like tinymce? If your website requires a Firefox add-on for full functionality then YOUR SITE is broken. Don't blame the add-on, and definitely don't blame the browser when things go wrong. Joomla and wikipedia can do it without problems! do it right or STFU
tinymce isn't an addon. tinymce is a JavaScript library for making a standard HTML textarea look and act like a RichText text box.
Which is why it breaking is a Firefox bug.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
So you're telling that anyone who knows Chrome v4 will feel right at home with Chrome v18? Awesome!
The thing is, I'm not using Firefox, I'm using Slashdot. Firefox is analogous to the display, keyboard and mouse here: it's a necessary evil that ideally stays in the background as much as possible. Any new and innovative features are more likely to get in the way than be helpful, especially if they happen in the UI.
Or even better analogy: browser UI is like inept political propaganda the author just couldn't stop himself from inserting into an otherwise decent book: it's there and you can't do anything but skim over it hoping to get back to the good parts soon.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
That's because chrome wasn't doing any hardware acceleration. I don't want Firefox not using a feature just because your video drivers are buggy. The problem is definately in them. I don't care what calls you make to the video driver, it still should not bsod. Ati is just being stupid. Sorry you are stuck with them, but it's not surprising. It's been very well known that the ati drivers are terrible.
From an add-on developer perspective, Firefox's frantic updates are a pain. I have the same add-on for Firefox and Google Chrome. Most of the code is common. On the Firefox side, I have work-arounds for two bugs in Firefox, and they've been open bug reports in Bugzilla for many months. There's a new bug this week because the last update to the Mozilla add-on SDK broke something in message passing. That's supposedly fixed in the next version of the SDK being released today. Now I have to rebuild, update and test my add-on, then run it through the Mozilla approval bureaucracy again. (Yes, the AMO web site says this happens automatically. That's only true if you let them host the source code.)
Over on Google Chrome, it just works. No workarounds needed. A stable API. No updates needed from my side.
I get far more downloads of the Firefox version, though.