(Bah!)
"OpenWebapps.js" isn't a file that's part of Firefox. I strongly suspect your problem is being caused by some addon. Try starting in Safe Mode to confirm that fixes the problem, then try disabling addons until you find the one causing it.
I'd like to know which addon was causing this!

I'm not hitting error #1 on Ubuntu, Firefox 9.0.1, so it might be distro-specific. As far as I can tell Firefox 9.0.1 shouldn't normally ship with the webapps directory, but Firefox 10 does.
The error can be easily tested in the Error Console, typing this:
> Components.classes["@mozilla.org/childprocessmessagemanager;1"].getService(Components.interfaces.nsISyncMessageSender)
Firefox 9 should show error #1, while 10 should show this message:
> [xpconnect wrapped nsISyncMessageSender]
If the Add-ons Manager is doing something with the OpenApps script in this particular Firefox distribution, then that could be the cause of this bug.

Something seriously screwy is going on in Fedora's Firefox install as far as I can tell. It seems to install xulrunner as a dependency for Firefox, despite installing a fully functioning Firefox distribution. But it installs xulrunner 7 alongside Firefox 9, and pulls some files from the omni.jar of each. So the component that provides navigator.mozApps is from Gecko 7, as far as I can tell Gecko 9 is what's running, and the attempt to access navigator.mozApps is throwing due to the incompatibility.
I'm not sure if it's AMO's place to try to work around this. It seems to be quite clearly a Fedora bug.

(In reply to Kris Maglione [:kmag] from comment #12)
> Something seriously screwy is going on in Fedora's Firefox install as far as
> I can tell. It seems to install xulrunner as a dependency for Firefox,
> despite installing a fully functioning Firefox distribution. But it installs
What exactly is a "fully functioning Firefox distribution" ?
> xulrunner 7 alongside Firefox 9, and pulls some files from the omni.jar of
erm, no. Fedora's xulrunner is built from http://releases.mozilla.org/pub/mozilla.org/firefox/releases/9.0.1/source/firefox-9.0.1.source.tar.bz2
and I hope that's not xulrunner 7.
Also, correcting comment 10; OpenWebapps.jsm is included in the FF 9.0.1 binary from mozilla.org. So, I'm not sure why people keep claiming it's not there. But, I also don't know what's different about the bits Fedora ships that causes problems.

I misread the install log. It said that xulrunner 7 was being installed, but my package list shows 9. And I see now that the shipped Firefox is more fragmentary than I'd realized. RedHat is a foreign land for me. I'm only looking into this because I was asked to.
I'm not sure where OpenWebapps.jsm came into this. The file at issue is the OpenWebapps.js component, which Firefox 9 neither ships nor registers, but which the Fedora xulrunner both ships and registers a navigator property for. In officially shipped Firefox 9 versions, that file is not included, nor is the OpenWebapps.manifest which registers it.
The other peculiarity with the Fedora setup, which may or may not be relevant, is that while the script loader seems to be able to access the cached bytecode for the component from the xulrunner omni.jar, resource:///components/OpenWebapps.js is not accessible from a running Firefox instance.

(In reply to Justin Dolske [:Dolske] from comment #2)
> "OpenWebapps.js" isn't a file that's part of Firefox.
*sigh* I should have checked further.
OpenWebapps.js and OpenWebapps.jsm _were_ part of Firefox, sort of. They landed in bug 609043 (for Firefox 9), and were renamed/moved in bug 697383 (for Firefox 11+).
When this code landed in Firefox 9, proper packaging was only added for Fennec, so only part of it would have been included in FF9 (and is presumably broken). For Firefox 11 it looks like the packaging is in place, so it presumably works in desktop Firefox now (as webapps.js / webapps.jsm)
Also, neither of these landing had proper reviewers. Nor did either include tests. Not good.

(In reply to Justin Dolske [:Dolske] from comment #16)
> (In reply to Justin Dolske [:Dolske] from comment #2)
>
> > "OpenWebapps.js" isn't a file that's part of Firefox.
>
> *sigh* I should have checked further.
>
> OpenWebapps.js and OpenWebapps.jsm _were_ part of Firefox, sort of. They
> landed in bug 609043 (for Firefox 9), and were renamed/moved in bug 697383
> (for Firefox 11+).
> When this code landed in Firefox 9, proper packaging was only added for
> Fennec, so only part of it would have been included in FF9 (and is
> presumably broken). For Firefox 11 it looks like the packaging is in place,
> so it presumably works in desktop Firefox now (as webapps.js / webapps.jsm)
Why is this included at all in any release of desktop Firefox? The original Fx9 patches only package for mobile.
> Also, neither of these landing had proper reviewers. Nor did either include
> tests. Not good.
In comment 18 of bug 609043, I did mention that a second full review would be needed whenever this functionality is ever used in desktop Firefox. Perhaps leaving it in /mobile/components would have been better.

(In reply to Gregory Koberger (:gkoberger) from comment #19)
> This could be merely a coincidence, however each time (so far, three) I've
> seen this bug reported it's been by a user using a non-English locale.
>
> Maybe this isn't relevant, but I figured I'd point it out.
It is irrelavant, I tried to start firefox with "LANG=C firefox" and it gave exactly the same results.

(In reply to Mark Finkle (:mfinkle) from comment #17)
> In comment 18 of bug 609043, I did mention that a second full review would
> be needed whenever this functionality is ever used in desktop Firefox.
> Perhaps leaving it in /mobile/components would have been better.
Tracking to either make bug 609043 mobile-specific for FF10 or to figure out a fix which would presumably be a subset of 697383 (whichever is lowest risk). If a fix is found too late in the cycle, the number of reports we've had so far may not justify the risk involved.

(In reply to Heiko Adams from comment #24)
> IMHO this is a potential blocker bug for firefox 10 - or am I wrong?
It's difficult to call it a blocker when we shipped FF9 with this issue and did not chemspill for it. It is, however, being tracked. I have no reason to believe that it will be left unresolved in FF10.

(In reply to Fabrice Desré [:fabrice] from comment #26)
> I pulled a beta tree (and an aurora one also), but I don't see
> OpenWebapps.js being packaged for desktop in this tree. Either I'm missing
> the obvious, or this bug is not on our side.
When building XULRunner, we package "everything that is built" since we do not have a package manifest for XULRunner. Since OpenWebapps.js is built as part of toolkit, the packaging phase sucks it in with everything else. Moving the webapps stuff out of toolkit would keep it out of XULRunner. Finding some way to _not_ build it (in the makefile) is another way.

(In reply to Fabrice Desré [:fabrice] from comment #28)
> Created attachment 589914[details][diff][review]
> patch
>
> With this patch we only build the mozapps/webapps directory for Android.
In order for this fix to make it into FF10, please nominate for Aurora/Beta tomorrow if you feel this patch is low risk.

> In order for this fix to make it into FF10, please nominate for Aurora/Beta
> tomorrow if you feel this patch is low risk.
I'd like to nominate it, but it looks like bugzilla does not let me do it. Maybe because it's filled in the amo product?

(In reply to Fabrice Desré [:fabrice] from comment #31)
> > In order for this fix to make it into FF10, please nominate for Aurora/Beta
> > tomorrow if you feel this patch is low risk.
>
> I'd like to nominate it, but it looks like bugzilla does not let me do it.
> Maybe because it's filled in the amo product?
a=akeybl, let's land on Aurora 11 and Beta 10.