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
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.
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
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
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.