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

Comments

Extended Support Release

[Harshmage]

Use the ESR version and don't stress about major version changes until November-ish.

Re:Extended Support Release

[Kobyov]

http://www.mozilla.org/en-US/firefox/organizations/ It's great really, makes the updates much more like the 3.6 era, when they did things sensibly

Re:Extended Support Release

[AliasMarlowe]

Of course, you don't have to worry about having any features then, either.

Not necessarily. I use Opera as choice 1 and Chromium as choice 2 (both on the Windows laptop at work and the Linux laptop/PCs at home). Both have adequate anti-scripting and ad-blocking support.

Re:Extended Support Release

[Intrepid imaginaut]

I have over 90 tabs open for weeks on end in firefox, memory usage rarely if ever goes past half a gig.

Re:My solution Works most of the time

[The MAZZTer]

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.

works for me

[Pretzalzz]

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.

Why is there a compatibility problem?

[Anaerin]

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.