Last Comment Bug 713468 - xulrunner builds include OpenWebapps.js, breaking add-on installation in Fedora
: xulrunner builds include OpenWebapps.js, breaking add-on installation in Fedora
Status: RESOLVED FIXED
:
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Public Pages (show other bugs)
: unspecified
: All Linux
: P1 critical
: ---
Assigned To: [:fabrice] Fabrice Desré
:
Mentors:
Depends on:
Blocks: 609043
  Show dependency treegraph
 
Reported: 2011-12-25 13:08 PST by Heiko Adams
Modified: 2016-02-04 14:51 PST (History)
20 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (663 bytes, patch)
2012-01-19 11:01 PST, [:fabrice] Fabrice Desré
mark.finkle: review+
Details | Diff | Review

Description Heiko Adams 2011-12-25 13:08:49 PST
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.
Comment 1 Justin Dolske [:Dolske] 2011-12-25 17:16:58 PST
"OpenWebapps.js" isn't a file that's part of
Comment 2 Justin Dolske [:Dolske] 2011-12-25 17:20:04 PST
(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!
Comment 3 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2011-12-25 17:51:36 PST
Pretty OpenWebapps.js is from the Open WebApps addon from Labs (aka Mozilla Labs App Runtime). Heiko, could you confirm you have that installed?
Comment 4 Heiko Adams 2011-12-26 01:48:33 PST
No, I don't have that extension installed and I've got the same problem with a new, clean profile
Comment 5 Heiko Adams 2011-12-26 01:54:10 PST
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
Comment 6 Heiko Adams 2011-12-26 02:00:47 PST
The problem still exists if all addons are disabled.
Comment 7 :Ms2ger 2011-12-26 12:46:29 PST
Errors 2 and 3 seems to suggest something is wrong on amo
Comment 8 Andrew Schultz 2011-12-27 09:41:14 PST
(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.
Comment 9 Justin Scott [:fligtar] 2011-12-27 09:55:38 PST
Seeing similar reports at https://forums.mozilla.org/addons/viewtopic.php?f=20&t=4514
Comment 10 Jorge Villalobos [:jorgev] 2011-12-27 15:12:34 PST
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.
Comment 11 Wil Clouser [:clouserw] 2011-12-27 15:18:32 PST
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?
Comment 12 Kris Maglione [:kmag] 2011-12-27 17:30:12 PST
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.
Comment 13 Andrew Schultz 2011-12-27 18:43:55 PST
(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.
Comment 14 Kris Maglione [:kmag] 2011-12-27 19:12:21 PST
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.
Comment 15 Andrew Schultz 2011-12-27 19:39:43 PST
(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.
Comment 16 Justin Dolske [:Dolske] 2011-12-27 21:36:44 PST
(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.
Comment 17 Mark Finkle (:mfinkle) (use needinfo?) 2011-12-27 21:58:53 PST
(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.
Comment 18 Jorge Villalobos [:jorgev] 2011-12-28 07:48:08 PST
Adding tracking flags. From comment #16 it appears that this could affect Firefox 10 as well.
Comment 19 Gregory Koberger (:gkoberger) 2011-12-28 09:30:51 PST
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.
Comment 20 nathansamson+mozillabugzilla 2011-12-28 09:48:52 PST
(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.
Comment 21 Alex Keybl [:akeybl] 2012-01-03 12:12:59 PST
(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.
Comment 22 Cameron Kaiser [:spectre] 2012-01-03 13:20:53 PST
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) { }
+       };
+}
Comment 23 Alex Keybl [:akeybl] 2012-01-04 13:26:36 PST
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?
Comment 24 Heiko Adams 2012-01-04 13:43:07 PST
IMHO this is a potential blocker bug for firefox 10 - or am I wrong?
Comment 25 Alex Keybl [:akeybl] 2012-01-04 15:26:04 PST
(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.
Comment 26 [:fabrice] Fabrice Desré 2012-01-04 18:27:36 PST
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.
Comment 27 Mark Finkle (:mfinkle) (use needinfo?) 2012-01-04 19:19:32 PST
(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.
Comment 28 [:fabrice] Fabrice Desré 2012-01-19 11:01:40 PST
Created attachment 589914 [details] [diff] [review]
patch

With this patch we only build the mozapps/webapps directory for Android.
Comment 29 Mark Finkle (:mfinkle) (use needinfo?) 2012-01-22 02:28:24 PST
Comment on attachment 589914 [details] [diff] [review]
patch

This should be enough to keep the webapps code from appearing in XULRunner builds
Comment 30 Alex Keybl [:akeybl] 2012-01-22 17:57:09 PST
(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.
Comment 31 [:fabrice] Fabrice Desré 2012-01-23 09:45:22 PST
> 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?
Comment 32 Alex Keybl [:akeybl] 2012-01-23 14:00:10 PST
(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.
Comment 33 Alex Keybl [:akeybl] 2012-01-23 14:03:47 PST
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.
Comment 34 [:fabrice] Fabrice Desré 2012-01-23 14:18:18 PST
this will never land on m-c since the code was removed in bug 697383 (for Firefox 11+)
Comment 35 [:fabrice] Fabrice Desré 2012-01-23 16:12:02 PST
pushed:
https://hg.mozilla.org/releases/mozilla-beta/rev/3a99d7ff459c
Comment 36 Takanori MATSUURA 2012-06-27 20:13:37 PDT
Do we have to leave this bug open?
Comment 37 Jorge Villalobos [:jorgev] 2012-06-28 08:13:49 PDT
It looks like this was fixed for all intended purposes.

Note You need to log in before you can comment on or make changes to this bug.