I bumped into this annoyance while updating my openSUSE 11.4 workstation tonight.
There are numerous mentions of this issue on the net, and numerous suggestions for addressing it. However, none of them (which I saw) really hits on the underlying problem, which is that somewhere, somehow, XPCOM can't start.
To understand what's going on, it's important to have a basic understanding of what XPCOM is, and how it is involved with Mozilla apps. XPCOM is an acronym for "Cross Platform Component Object Model," which is Mozilla's equivalent technology to CORBA or Microsoft's COM. Like any other "object model," XPCOM's function is to provide a modular framework vs a monolithic one. This modularization allows XPCOM to be (mostly) platform-neutral, making it possible to run the Gecko rendering engine on a variety of platforms. So, as the Gecko engine is composed of XPCOM components, if XPCOM cannot start, Gecko cannot start. If Gecko cannot start, then there is no rendering engine for the application, essentially stopping whichever Mozilla-based app one might wish to run, before it even gets started.
What can cause XPCOM to not load?
Like any other application, XPCOM has various version requirements for its various components. Newer versions are not necessarily compatible with older ones, and are rarely tested for interoperability. As XPCOM is installed as a module set, it would be counter-productive to spend much time ensuring backward compatibility for something which ships in a complete state, anyway. Other reasons can be misconfiguration (mainly path errors, where the binary can't find the XPCOM modules to load them) or broken or missing modules.
In my case, I tried installing several updated versions of Firefox (I started with 4.0.1). While SeaMonkey 2.3.3 had no issues whatsoever, every version of Firefox greater than 4.0.1 failed to start. Normally, I update and install apps using zypper (e.g., zypper up MozillaFirefox). In this case, I even tried Yast's software management, all to no avail.
Finally, I rolled up my sleeves and went straight to the filesystem. After removing Firefox via zypper, I found that a number of leftover modules were left in the application directory, a sure sign of trouble to come. Once I cleaned out the directory and installed 7 (yes, I went right for the latest, bleeding edge beta), Firefox worked just as expected.
Not one of the search hits I found mentioned checking for old modules left behind from previous installs. (Apparently, instead of loading the new components from theXULrunner install, Firefox saw a module in the same directory as firefox-bin, and tried to load that, instead (path order, not path error).