This recent news concerning the next Beta release of Firefox 4 which is due out either later today or Monday surprises me. While it is not unusual for developmental releases to break current extensions it seems odd that Mozilla would choose to do this during the Beta phase and this is going to break a lot more extensions than ‘normal’. Usually by the time a an upcoming major Firefox release reaches the beta phase major changes have already been implemented. However, Firefox 4 Betas are a little different than previous Betas.

Prior releases were labeled as Firefox 3.7/Gecko 1.9.3 and were still being built on the current Gecko 1.9.x rendering engine. When the first beta came out earlier this month for this upcoming version of Firefox it was re-numbered to Firefox 4 because now it is being built off of the new Gecko 2.0 rendering engine.

The breakage is due to an XPCOM change and being implemented as part of Gecko 2. CyberNet News’ Ryan explains in Firefox 4 Beta 2 Will Break Many Extensions (emphasis is mine):

This XPCOM change. Many extensions, including CyberSearch, use what’s referred to as components in their code. This change landed in the nightly releases shortly after Firefox 4 Beta 1 was made available, and it reworks the way these components get registered with the browser. The fix is pretty easy, and should take extension developers very little time (took me about 30 minutes) to update their add-ons. The problem is that there are so many add-ons that have been abandoned by their developers, and that will likely leave a lot of users frustrated.

So why the change? Well, it’s better in the long run. Previously if you did anything with an extension (install, remove, enable, disable, etc…) you would have to restart your browser, and doing so would require ALL of your browser components to have to re-register. With the way it was set up every component would be “loaded and executed, then unloaded, then reloaded again during the restart.” You’ll still need to restart your browser after installing/updating extensions, but now the components are pulled directly out of the extension’s manifest file which avoids many of the otherwise poor side effects. Not only that, but as Mozilla points out this is a good move in helping to make Firefox multithreaded.

Unfortunately this new change means it is no longer going to be as simple as downloading the extension to your local system and hacking the install.rdf file then installing the modified extension. Simply bumping the max version as described in the Manually Updating Add-ons to Work post from last month likely won’t work any longer. While Ryan says the fix pretty easy and only about took 30-minutes, he is an extension developer. Somehow I doubt this is going to be something the average to semi-advanced Firefox user is going to be able to do to make their favorite extension work with Firefox 4. This is defiantly something I am going to have do some more research on. Look for a/some follow-up post(s) in the coming days.