Closed
Bug 713468
Opened 13 years ago
Closed 12 years ago
xulrunner builds include OpenWebapps.js, breaking add-on installation in Fedora
Categories
(addons.mozilla.org Graveyard :: Public Pages, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bugzilla, Assigned: fabrice)
References
Details
Attachments
(1 file)
663 bytes,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•13 years ago
|
Summary: addons.mozilla.org → unable to install addons from addons.mozilla.org
Comment 1•13 years ago
|
||
"OpenWebapps.js" isn't a file that's part of
Comment 2•13 years ago
|
||
(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•13 years ago
|
||
Pretty OpenWebapps.js is from the Open WebApps addon from Labs (aka Mozilla Labs App Runtime). Heiko, could you confirm you have that installed?
Reporter | ||
Comment 4•13 years ago
|
||
No, I don't have that extension installed and I've got the same problem with a new, clean profile
Reporter | ||
Comment 5•13 years ago
|
||
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
Reporter | ||
Comment 6•13 years ago
|
||
The problem still exists if all addons are disabled.
Comment 7•13 years ago
|
||
Errors 2 and 3 seems to suggest something is wrong on amo
Component: General → Public Pages
Product: Firefox → addons.mozilla.org
QA Contact: general → web-ui
Version: 9 Branch → unspecified
Comment 8•13 years ago
|
||
(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•13 years ago
|
||
Seeing similar reports at https://forums.mozilla.org/addons/viewtopic.php?f=20&t=4514
Severity: normal → critical
OS: Linux → All
Priority: -- → P1
Hardware: x86_64 → All
Comment 10•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•13 years ago
|
OS: All → Linux
Comment 13•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
Adding tracking flags. From comment #16 it appears that this could affect Firefox 10 as well.
tracking-firefox10:
--- → ?
tracking-firefox9:
--- → ?
Summary: unable to install addons from addons.mozilla.org → xulrunner builds include OpenWebapps.js, breaking add-on installation in Fedora
Comment 19•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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?
Assignee: nobody → fabrice
Reporter | ||
Comment 24•13 years ago
|
||
IMHO this is a potential blocker bug for firefox 10 - or am I wrong?
Comment 25•13 years ago
|
||
(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.
Assignee | ||
Comment 26•13 years ago
|
||
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•13 years ago
|
||
(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.
Assignee | ||
Comment 28•13 years ago
|
||
With this patch we only build the mozapps/webapps directory for Android.
Attachment #589914 -
Flags: review?(mark.finkle)
Comment 29•13 years ago
|
||
Comment on attachment 589914 [details] [diff] [review]
patch
This should be enough to keep the webapps code from appearing in XULRunner builds
Attachment #589914 -
Flags: review?(mark.finkle) → review+
Comment 30•13 years ago
|
||
(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.
Assignee | ||
Comment 31•13 years ago
|
||
> 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•13 years ago
|
||
(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•13 years ago
|
||
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.
Assignee | ||
Comment 34•13 years ago
|
||
this will never land on m-c since the code was removed in bug 697383 (for Firefox 11+)
Assignee | ||
Comment 35•13 years ago
|
||
Updated•13 years ago
|
Blocks: 609043
status-firefox10:
--- → fixed
Comment 36•12 years ago
|
||
Do we have to leave this bug open?
Comment 37•12 years ago
|
||
It looks like this was fixed for all intended purposes.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•