User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20100101 Firefox/9.0 Build ID: 20111220101134 Steps to reproduce: Opening an addons details page like https://addons.mozilla.org/de/firefox/addon/ghostery/?src=hp-dl-featured. It's not possible to install an addons and the list of similar addons isn't loading Actual results: Firefox error log shows 3 errors: 1) Fehler: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource:///components/OpenWebapps.js :: OpenWebapps :: line 50" data: no] 2) Fehler: z.button is undefined Quelldatei: https://static-ssl-cdn.addons.mozilla.net/de/firefox/addons/buttons.js?b=01ad944 Zeile: 13 3) Fehler: $(".install").installButton is not a function Quelldatei: https://static-ssl-cdn.addons.mozilla.net/media/js/impala-min.js?build=01ad944 Zeile: 1 Expected results: The page should load as expected and it should be able to install addons.

"OpenWebapps.js" isn't a file that's part of

(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!

Pretty OpenWebapps.js is from the Open WebApps addon from Labs (aka Mozilla Labs App Runtime). Heiko, could you confirm you have that installed?

No, I don't have that extension installed and I've got the same problem with a new, clean profile

But wait. I can remember I've installed that addon some months ago but removed it in the meantime. Maybe it has been uninstalled incompletely

The problem still exists if all addons are disabled.

Errors 2 and 3 seems to suggest something is wrong on amo

(In reply to Justin Dolske [:Dolske] from comment #2) > "OpenWebapps.js" isn't a file that's part of Firefox. For some definition of "Firefox", yes. https://hg.mozilla.org/releases/mozilla-release/file/90427ed5738e/toolkit/mozapps/webapps It's part of the source and it gets built (and packaged) by default for me using a 9.0.1 source tree. Heiko and others are hitting this with Fedora, which ships OpenWebApps with xulrunner.

Seeing similar reports at https://forums.mozilla.org/addons/viewtopic.php?f=20&t=4514

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.

Thanks Jorge. Chris also looked at this earlier. It's not clear to me if this is an AMO bug or a browser bug. Can someone who knows describe the problem and the best solution?

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 Kris Maglione [:kmag] from comment #14) > 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... OK, I see the distinction now... .mozilla.org's firefox 9.0.1 tar.bz2 andrew@bill#unzip -l omni.jar | grep -i openw [complaining about unhappy zip format] 8866 01-01-2010 00:00 modules/OpenWebapps.jsm 11992 01-01-2010 00:00 jsloader/resource/gre/modules/OpenWebapps.jsm fedora's xulrunner 9.0.1 rpm andrew@bill#unzip -l omni.jar | grep -i openw 10993 12-20-2011 23:28 components/OpenWebapps.js 383 12-20-2011 23:28 components/OpenWebapps.manifest 15724 12-20-2011 23:28 jsloader/resource/gre/components/OpenWebapps.js 11992 12-20-2011 23:28 jsloader/resource/gre/modules/OpenWebapps.jsm 8866 12-20-2011 23:28 modules/OpenWebapps.jsm .mozilla.org's xulrunner 9.0.1 .tar.bz2 andrew@bill#unzip -l omni.jar | grep -i openw 10993 01-01-2010 00:00 components/OpenWebapps.js 383 01-01-2010 00:00 components/OpenWebapps.manifest 8866 01-01-2010 00:00 modules/OpenWebapps.jsm 15724 01-01-2010 00:00 jsloader/resource/gre/components/OpenWebapps.js 11992 01-01-2010 00:00 jsloader/resource/gre/modules/OpenWebapps.jsm if components/OpenWebapps.js shouldn't be there, then it would seem to be a xulrunner problem and not a fedora one.

(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.

Adding tracking flags. From comment #16 it appears that this could affect Firefox 10 as well.

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. Perhaps a unicode issue? * This bug report (German) * Fligtar's link https://forums.mozilla.org/addons/viewtopic.php?f=20&t=4514 (Polish) * Blog comment http://blog.mozilla.com/webdev/2011/12/27/popcornjs_is_a-maize-ing/#comment-219988 (Dutch) Maybe this isn't relevant, but I figured I'd point it out.

(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.

For what it's worth, this bug burned us in TenFourFox 9 and we got around it with a minimal patch, essentially creating a dummy stub if the call fails. +try { this.mm = Cc["@mozilla.org/childprocessmessagemanager;1"].getService(Ci.nsISy ncMessageSender); +} catch(e) { + // Create a stub so that the creek don't rise. (10.4Fx issue 117) + this.mm = { + addMessageListener : function(x, y) { }, + sendAsyncMessage : function(x, y) { } + }; +}

Fabrice - can you take this one for FF10 (in the next couple of weeks) since it appears to be a regression from the push of 609043?

IMHO this is a potential blocker bug for firefox 10 - or am I wrong?

(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.

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.

(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.

With this patch we only build the mozapps/webapps directory for Android.

Comment on attachment 589914 [details] [diff] [review] patch This should be enough to keep the webapps code from appearing in XULRunner builds

(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.

I just noticed that this hasn't landed on m-c yet. Let's make sure we're all green before landing on Beta 10.

this will never land on m-c since the code was removed in bug 697383 (for Firefox 11+)

pushed: https://hg.mozilla.org/releases/mozilla-beta/rev/3a99d7ff459c

Do we have to leave this bug open?

It looks like this was fixed for all intended purposes.