Pages

Saturday, May 31, 2008

I'm not particularly fond of Firefox's XUL+js architecture, but I'm more than willing to live with this unusual choice if it allows people to easily write Firefox extensions to customize their experience.

But did you ever notice that most of the plugins break every time you update Firefox? I thought that APIs which change this fast must reflect a development model where refactoring is frequent. I'm glad when teams decide that code quality is more important that backward compatibility, but my enthusiasm doesn't seem to be widely shared.

As a side-note, I think that the developers of the Linux kernel have found a great way to please everyone. They maintain backward compatibility for their external interface, the system calls which all Linux applications use, while allowing themselves to refactor their internal interface at will. This is unfortunately not enough since drivers depend on this internal interface, just like Firefox plugins depend on the browser's internal XUL interface. But instead of requiring driver developers to update their code at every release, the kernel team encourages driver developers to commit their code to the kernel tree and to let the kernel developers update the drivers themselves.

Today, I've upgraded Firefox from version 3 beta 5 to version 3 RC1, and as usual it broke many of my plugins. Now, the shocking part is that there isn't supposed to be any change at all between those two versions! So if the internal API didn't change... Could it be that the plugins were broken by something bogus?

What happened is that Firefox's extension mechanism requires each plugin to specify a range of versions on which it is supposed to work, and they're not supposed to pretend that they work on versions which haven't been released yet. What a bad idea! This means that every single Firefox release will break every single plugin except those that cheat and pretend to know the future. This in turn means that every single plugin needs a maintainer to diligently follow Firefox's release schedule and to bump the range of his plugin every time. How boring! I'd rather have those people working on new extensions.

So in case your favorite plugin's maintainer is too bored to do this, here's how to do it yourself.