Let Older Add-Ons Work With Firefox 3.0

mask.of.sanity informs us of a hack that allows old add-ons to work with Firefox 3.0. Short form: in about:config, create a new boolean and set extensions.checkCompatibility to false. "The fix, which requires a little boolean creativity, great for anyone not afraid of taking risks. The idea is to stop Firefox checking its version history, allowing defunct extensions to work... [Those who do] get the fix working will have to remove the code from the prefs.js file once the stable Firefox comes out, but will enjoy their [favorite extensions] in the meantime."

Do not do this

Not only is this not news, but it's a bad idea. Straight from the horse's mouth: [mozillazine.org]

You can not make your extensions compatible by changing a Firefox preference.

So don't do it unless you're fully prepared to deal with major breakage!

Re:Do not do this

While it may cause breakage its a great way for users of the beta and RC version of Firefox 3 to get some fairly major extensions work.

I need IEtab to get certain work pages to work and I really love stumbleupon... So when Firefox 3 upgraded automatically to RC1 and these broke it was quite annoying so i disabled the check.

An example of an extension this wont fix is Google Browser Sync. You will need to disable this in Firefox 3 otherwise you WILL see some major breakage if you disable the check.

Re:

I would fully expect IETab to crash, in general, unless you're using it with the exact version of Gecko it was compiled against (or one completely binary-compatible with it, like the security releases are).

Re:Do not do this

Why? IETab doesn't use Gecko, it uses IE. That's the entire point of it.

Re:Do not do this

Odd, IE Tab is working fine here on FF 3 RC 1 without any modifications. That said, I find a safer way to get your favourite extensions working is to edit the version number in install.rdf which is inside the .xpi file (xpi is just a renamed zip file). That way when the extension updates normally, the hack doesn't stick around ready to break something later.

Re:Do not do this

While it is fine to disable the compatibility checking, my concern is that if enough people disable it they might start expecting the Mozilla devs to actually implement workarounds to 2.0 compat problems in v3. That way leads to many, many problems. Just ask Microsoft.

Re:Do not do this

If I remember correctly, one of the top crashes for Firefox 3 betas was... people whole force-enabled Google Toolbar.

Yes, top crash.

This preference is generally not useful unless you know how to deal with the fallout (including figuring out what problems are due to extensions and which ones are not, and possibly fixing things locally).

Re:Do not do this

You DO realize safe-mode exists so you can uninstall and disable extensions without having them running, so they can't crash Firefox.

Re:Do not do this

This isn't about making extensions compatible, it's about forcing Firefox to allow you to use extensions that claim not to be compatible, but very well might be. Major breakage certainly could occur, but I find it worth the risk. Many extensions that I was using with beta5 claimed not to work in rc1. Forcing them to load anyway has been very helpful, and they have all worked perfectly without causing any problems (as far as I can tell).

Finding out incompatibilities in advance?

On that note, is there any -easy- way to check addon compatibility before upgrading to FF3, i.e. other than looking each addon up again? As I understand it they all have a builtin version range, why can't I just go to my addon list and see the compatibility of each addon?

Is this a good idea?

If FF3 is being used before a v1 release, it ought to be used in order to find bugs so that the development team can fix them for the release version. By breaking a specific part of the product in order to install unsupported addons, users are adding unecessary unknowns to the equation and negating their contributions to the product test cycle.

I'd say hold off on FF3 until it is released if you can't live without your plugins.

Re:Is this a good idea?

I'd say hold off on FF3 until it is released if you can't live without your plugins.

While I planned on waiting until Firefox 3 is released before switching, I found it preinstalled in Ubuntu 8.04. So I'm using it. I do think that Ubuntu made a bad decision by including a beta web browser, I understand why they did that. The problem is not that the Firefox betas and RCs are buggy. The problem is that misuse of the term beta has led people to expect no less from a beta than from a full release. Gmail has been in beta for years, and it is [arguably] the most complete, feature-rich webmail available. How long was ethereal beta? 10 years? It was pretty stable for at least the past five years, at least, no less than any other full release software. Beta has become a marketing term for "new".

Re:Is this a good idea?

In the same vein, shouldn't extension developers follow the Fx beta stages so that users will actually switch to 3.0 once it is released, instead of having to wait for months until their plugins have left beta stage?

I use about 10 plugins since Fx 1.0, and have yet to encounter a single crash due to an extension (the only plugins that crash my browser are GCJ and Flash). Disabling compatibility checking has been a blessing for me, because it means I can use the latest version of Firefox and still use all extension that I don't want to browse without.

(Before I knew of this option, I used to manually edit the extensions manifest file to fake compatibility with newer versions)

A bit less strict disabling rules, please

I always wondered why some extensions got disabled from one minor bugfix release to the next. Has the underlying API been changed so much, that the extension really isn't going to work anymore or is the extension's author just being a bit restrictive with the "max. version allowed" setting?

Re:A bit less strict disabling rules, please

There is a goal inside of Mozilla not to break extension compatibility for minor releases, and the documentation on their website suggests using maxVersion of the form 2.0.0.* for Firefox 2:

http://developer.mozilla.org/en/docs/Updating_extensions_for_Firefox_2#Step_1:_Update_the_install_manifest [mozilla.org]

For Firefox 3, they suggest moving to the form 3.0.*:

http://developer.mozilla.org/en/docs/Updating_extensions_for_Firefox_3#Step_1:_Update_the_install_manifest [mozilla.org]

So no, devs aren't breaking any rules when they mark their extension as being forward compatible.

What is this?

What is this, the 'tips n tricks' column of a newspaper's IT section?

The fix, which requires a little boolean creativity, great for anyone not afraid of taking risks.

Not afraid of taking risks? It's about:config, not instructions for making a Linux-powered flamethrower, which I think would be a much better article for Slashdot.

Re:What is this?

I'd advise against the Linux-powered flamethrower, as I almost melted my face off trying to recompile its kernel.

Re:What is this?

I'm sure I'll be safe with the Microsoft powered flame thrower.

Re:What is this?

Ah yes, the Blue Flame of Death!

Takes a long time to filter

Obviously tips like this take a long time to filter through to Slashdot, for some reason. I saw that tip when first using Firefox 3 betas, and according to the Mozillazine knowledgebase [mozillazine.org] it has been there since Firefox 2! It also covers an extra bit that the summary doesn't that might still stop extensions working in Firefox 3.

And after all that, I originally used the Nightly Tester Tools to check the compatibility of some extensions. Some of the simpler ones worked, but AdBlock Plus couldn't just have the FF2 version enabled (it wouldn't auto-fill the filter address, but they have an update) and neither could the Web Dev toolbar (the edit CSS tab wouldn't close, amongst other things). Both of them have now been updated for the RC.

I think this one is definitely tagged right - "!news". Now all it needs is "badidea".

Nightly Tester Tools

This addon [mozilla.org] lets you selectively override addons' compatibility, among other things.

This extension adds a few extras useful to those that regularly test nightly builds of Firefox, Thunderbird, Sunbird and Toolkit Seamonkey (Suiterunner).

The following is a brief list of the extension's features, for the full set of features please visit the extension home page.

• Extension compatibility fixing
• Titlebar customisation
• Build ID retrieval
• Screenshots
• Breakpad information
• Restoring tabs from previous session
• Leak log analysis

This is really, really stupid

Sure you can disable the mechanism that checks whether plugins are compatible.

However, as is to be expected with major version changes, lots of API's will likely have changed, so if the plugins happen not to crash outright, they might fail in subtle ways that you don't discover until it's much too late.

This is pretty much exactly why the mechanism is there in the first place.

So if you do this, don't complain about "bugs" regarding crashes, memory leaks and pretty much any other problems you may experience with Firefox. There likely will be a lot, if you go down this road.

Re:This is really, really stupid

Don't extensions run on some kind of VM or something? People yell at Windows for all of its stability problems, and practically everything in a modern web browser behaves like it's single-threaded?

I agree about the singlethreaded thing. Apart from that: no, extensions can't run in some kind of VM. If they did, they would not be able to modify the browser in interesting ways (as this in many cases needs r/w access to internal browser state; this would not be available if you run it in a "sandbox" or VM.

You can pretty much have the exact same argument about Linux kernel modules: the kernel refuses to load modules that are compiled for the wrong (=a different) kernel version. Now, you could say, modules should not be able to crash the kernel, right? Well...if you could limit the interface between kernel and modules in such a way that modules would probably run about 5x slower, needs twice the amount of code to write *and* be unable to do a lot of things that would be interesting because the strict interface does not allow this, then yes. If we don't want to make that sacrifice (and in fact we don't), the smarter way is to only allow modules to be loaded that are actually at least compiled against the correct kernel version.

We do live in 2008, right?

Last time I checked, yes. Your point being that software composition problems are just supposed to somehow magically solve themselves these days?

Speaking of hacking Beta Software...

Here is another boolean hack but for Vista! Just set that boolean variable

CRASH = TRUE
and
EATALLMYDAMNRESOURCESWITHDRM = TRUE

to FALSE

I wonder if I can set OMGIGOTAGIRLFRIEND = TRUE... THE POSIBILITIES!

Google bar kills my FF3

You have been warned :)

Recovery is to delete the plugin, something like this:
egrep -ri google .mozilla | grep toolbar
.. ( see where it lives ) ..
rm -rf .mozilla/firefox/zy8uo2wh.default/extensions/\{3112ca9c-de6d-4884-a869-9855de68056c\}