Closed Bug 109044 Opened 23 years ago Closed 21 years ago

Install error -239 registering chrome on some systems

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: pali, Assigned: ssu0262)

References

(
URL
)

Details

(Keywords: fixed1.4.1, Whiteboard: [adt3])

Attachments

(2 files)

patch for mozilla/xpinstall/src/nsRegisterChrome.cpp
367 bytes, patch
ssu0262
: review+
dveditz
: superreview+
asa
: approval1.4.1+
Details | Diff | Splinter Review
debugging patch for mozilla/xpinstall/src/nsRegisterChrome.cpp
6.23 KB, patch
Details | Diff | Splinter Review 
We are getting bug report about installation problems with latest linux
nightlies on MozGest. Doen't matter if user is root or not.

--mondo
Sorry I can't be more specific. Few people on #mozillazine tested this with
recent nightlies on W98, worked ok. Linux guys get -239. I don't know but it
looks like a linux specific issue AFAIK.
--mondo
Same linux testers report that thay have no problem to install jabberzilla nor
hermes. Here is our content.rdf:
<?xml version="1.0"?> <RDF:RDF
xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
            xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <RDF:Seq
about="urn:mozilla:package:root"> <RDF:li
resource="urn:mozilla:package:mozgest"/> </RDF:Seq> <RDF:Description
about="urn:mozilla:package:mozgest" 
        chrome:displayName="Mouse Gestures" 
        chrome:author="Andy Edmonds" 
        chrome:name="mozgest"> </RDF:Description>

<RDF:Seq about="urn:mozilla:overlays">
<RDF:li resource="chrome://navigator/content/navigator.xul"/>
<RDF:li resource="chrome://communicator/content/pref/preftree.xul"/>
</RDF:Seq>

<RDF:Seq about="chrome://navigator/content/navigator.xul">
<RDF:li>chrome://mozgest/content/mozgestOverlay.xul</RDF:li>
</RDF:Seq>

<RDF:Seq about="chrome://communicator/content/pref/preftree.xul">
<RDF:li>chrome://mozgest/content/pref/mozgestPrefOverlay.xul</RDF:li>
</RDF:Seq>

</RDF:RDF>
Reassigning QA Contact to Grace.  See if you can reproduce this problem.  -239
is CHROME_REGISTRY_ERROR
QA Contact: jimmylee → gbush
cannot reproduce this with Mozilla nightly build 2001110908 nor commercial trunk
build 2001110908
package loads without errors and when relaunch- Mouse gestures are working

I still confirm this bug on build 2001110908 linux 2.2 (Window Maker)
I cc'ed folks that experienced the same problem (Mozdev-bug 663)
What can we do to help you to investigate this problem?
duplicate of bug 29741?
I don't think so.
I tried to install mozgest as root (thus with write privileges) and the reported
error is -239, not -225.
We have this confirmed on Solaris.
See our mozdev bugzilla: 
http://mozdev.org/bugs/show_bug.cgi?id=663
I've seen this bug for a number of weeks (at least) under linux nightly builds,
both with mouse gestures and with (total) recall, another mozdev project. Still
in build 2001110815. There was talk that this was related to only builds
compiled by mozilla.org (IIRC), with reports of success if mozilla was built
from source.
Just to confirm that this is still present in 2002011021 (linux).
andrea says that this bug blocks localization. Are all xpi's
on linux are broken?

I tried installing the above url and it gave me the download
dialog but didn't download anything. Pressing cancel did nothing.
(using 2002012909, 0.9.8 branch)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm able to install everything I've tried one time. Some of the XPI's failed
when I attempted a second install of the same XPI (like optimoz and the brfr
0.9.7 localization XPI). I get an error -215.
I had reports about describing this behaviour, but now I've tested on
098 build 2002-01-30 and the bug seems gone.

The Chinese-China 097 lang pack still shows this behaviour, but its
fault of the installation script. (I'll fix it)

I've tested the optimoz 0.3.2 xpi and it works ok.
I've also tried to start the 0.3 xpi download and the installation dialog
triggers correctly.

Everything clear with this build for me.

If anyone still find incriminated xpi, please let me know (I'll try to take a
look). Thank you all.
Erase and rewind :)

Now I've tested the 0.9.7 release again (build 2001122108 on tar.gz).

At home with a SuSE 7.1 distro it gives me a straight -239 with any lp.
This is also reproduces with another Italian reporter with a SuSE 7.2.

Then I've tested 097 on a Red Hat 6.7 at Univ. It returns a -204 (= no install
script !!) stopping immediatly the xpi installation as reported by Dawn Endico.

Testing again the same mozilla installation, from the same folder, logged as the
same user, again with Red Hat 6.2 installed on the machine used for the test of
my  previous comments ( #13 ), the installation succeed, and I can see with no
problems Italian, German or whatever.

I think it might be a problems with libs.
I just decompress mozilla into a folder (I have all the rights on it) and add
the executables folder to my $PATH variable.

Any hint ?
Status: NEW → ASSIGNED
*** Bug 124809 has been marked as a duplicate of this bug. ***
I am seeing this when with release 0.9.8 (2002020415/linux),
when I try to install a language pack or the uabar. 

The odd thing is that no error dialog is shown, so the user 
restarts mozilla just to wonder why nothing has changed.

Is there a seperate bug for at least showing an error message
in case something goes wrong with install?
Originally we were told web designers wanted to control the experience, so the
error status is reported to the launching page via a callback. In practice,
however, more sites provide simple links and don't register the callback. bug
98458 covers adding error display to the standard UI.
nominating, the flakiness of this problem introduces significant risk to MachV.
Keywords: nsbeta1
required comment
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.9
syd: Wich kind of comments do you need ?
How can I help you ?
same problem bug 106701?
Arrgh. It really seems to be a duplicate of bug 106701.

I'm gonna leave it as a standalone bug waiting for comments from others (and
because I probably have not enough Bugzilla rights).
*** Bug 106701 has been marked as a duplicate of this bug. ***
handing to bryner since I strongly suspect a tie to bug 126113. When XPInstall
reports a -239 it means the chrome registry command failed. Since the same
package works on some machines (usually older ones) and not others I think the
chrome registry itself is the culprit.

There are differences from bug 126113, though, so I don't think it's a straight
duplicate. In that one the chrome is installed using the DELAYED_CHROME style
(like bug 106701) meaning through the installed-chrome.txt file, and the failure
is to write out the overlayinfo. In this we're trying to use the chrome registry
install() method and getting an error code.
Assignee: syd → bryner
Status: ASSIGNED → NEW
Summary: Error -239 on recent linux nightlies → Install error -239 registering chrome on newer Linux kernels
I'm citing inline the install.log tested
with the 2002030106 build under SuSE 7.1

I've used the 098 Italian lang pack you can
find at ftp://ftp.mozilla.org/pub/mozilla/l10n/lang/moz098/

The 2nd installation is referred to the very same package
with the DELAYED_CHROME flag.

-------------------------------------------------------------------------------
file:///home/Andrea/langitit.xpi  --  03/02/2002 00:48:50
-------------------------------------------------------------------------------

     ** initInstall: platformNode=unix
     Italian (it-IT) Language Pack
     -----------------------------

     ** initInstall: 0
     ** Base installation folder: /home/Andrea/moz099/
     ** addDirectory() returned: 0
     [1/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/mimeTypes.rdf
     [2/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/bookmarks.html
     [3/37]	Installing: /home/Andrea/moz099/chrome/IT.jar
     [4/37]	Installing:
/home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userChrome.css
     [5/37]	Installing: /home/Andrea/moz099/chrome/it-IT.jar
     [6/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/search.rdf
     [7/37]	Installing: /home/Andrea/moz099/chrome/it-unix.jar
     [8/37]	Installing:
/home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userContent.css
     [9/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/localstore.rdf
     [10/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/panels.rdf
     [11/37]	Installing: /home/Andrea/moz099/chrome/it-win.jar
     [12/37]	Installing: /home/Andrea/moz099/chrome/it-mac.jar
     [13/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/communicator/

     Install **FAILED** with error -239

     Install **FAILED** with error -239
     ** performInstall() returned: -239
     Finished Installation  03/02/2002 00:48:52

-------------------------------------------------------------------------------
file:///home/Andrea/ititdelayed.xpi  --  03/02/2002 00:49:24
-------------------------------------------------------------------------------

     ** initInstall: platformNode=unix
     Italian (it-IT) Language Pack
     -----------------------------

     ** initInstall: 0
     ** Base installation folder: /home/Andrea/moz099/
     ** addDirectory() returned: 0
     [1/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/mimeTypes.rdf
     [2/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/bookmarks.html
     [3/37]	Installing: /home/Andrea/moz099/chrome/IT.jar
     [4/37]	Installing:
/home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userChrome.css
     [5/37]	Installing: /home/Andrea/moz099/chrome/it-IT.jar
     [6/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/search.rdf
     [7/37]	Installing: /home/Andrea/moz099/chrome/it-unix.jar
     [8/37]	Installing:
/home/Andrea/moz099/defaults/profile/IT/chrome/esempio-userContent.css
     [9/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/localstore.rdf
     [10/37]	Installing: /home/Andrea/moz099/defaults/profile/IT/panels.rdf
     [11/37]	Installing: /home/Andrea/moz099/chrome/it-win.jar
     [12/37]	Installing: /home/Andrea/moz099/chrome/it-mac.jar
     [13/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/communicator/
     [14/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/content-packs/
     [15/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/cookie/
     [16/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/editor/
     [17/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/global/
     [18/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/messenger-mapi/
     [19/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/messenger-smime/
     [20/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/messenger/
     [21/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/mozldap/
     [22/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/navigator/
     [23/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/necko/
     [24/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/pipnss/
     [25/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/pippki/
     [26/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/wallet/
     [27/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/chatzilla/
     [28/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/inspector/
     [29/37]	Register Locale: jar:resource:/chrome/it-IT.jar!/locale/it-IT/venkman/
     [30/37]	Register Locale: jar:resource:/chrome/it-unix.jar!/locale/it-IT/global-platform/
     [31/37]	Register Locale:
jar:resource:/chrome/it-unix.jar!/locale/it-IT/communicator-platform/
     [32/37]	Register Locale:
jar:resource:/chrome/it-unix.jar!/locale/it-IT/navigator-platform/
     [33/37]	Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/communicator-region/
     [34/37]	Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/editor-region/
     [35/37]	Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/global-region/
     [36/37]	Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/messenger-region/
     [37/37]	Register Locale: jar:resource:/chrome/IT.jar!/locale/IT/navigator-region/

     Install completed successfully
     ** performInstall() returned: 0
     Finished Installation  03/02/2002 00:49:27
I'm really not convinced that 'newer linux kernels' is appropriate, assuming its
normal meaning. I get failure here with, currently, 2002022208 linux nightly,
under a system with a 2.0.36 kernel and debian testing/unstable!
fair enough. It's still a mystery what's actually causing the problem.
Summary: Install error -239 registering chrome on newer Linux kernels → Install error -239 registering chrome on some systems
not going to make 0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Whiteboard: [adt3]
No longer blocks: 115520
dveditz, do you think you could take this?  I doubt I'm going to be able to make
any progress on it.
Damn, you win the "most doomed" contest 10 to 7 (nsbeta1+). <sigh>

I have no idea where to begin :-(
Assignee: bryner → dveditz
I looked for whether to solve this problem. Therefor I incompetently
changed:
diff install.js 1/install.js:
44c44
<   registerChrome(Install.CONTENT , getFolder(mgDir, "content"));
---
>   registerChrome(5 , getFolder(mgDir, "content"));

Now it works! The value of Install.CONTENT is 4.
This has helped our XPI installer, though it is IMHO just a workaround...
We changed our install script to 
registerChrome(CONTENT | DELAYED_CHROME, getFolder(mgDir, "content"));
instead of 
registerChrome(CONTENT , getFolder(mgDir, "content"));
Users report that installation works for them.

--mondo
*** Bug 136981 has been marked as a duplicate of this bug. ***
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
*** Bug 140662 has been marked as a duplicate of this bug. ***
*** Bug 140949 has been marked as a duplicate of this bug. ***
*** Bug 111898 has been marked as a duplicate of this bug. ***
Can you do anything with this information:
http://multizilla.mozdev.org/xpi/linux-inst-error.txt ?
Don't know if this is just a personal impression, but the -239 problem is found
always when mozilla is installed from an RPM. Or at least installing moz from
the RPM distribution makes things go wrong (so I can't say if this another bug).
Probably in bug 140949, this is the case.
Andrea:
from my findings, it happens on almost any unix install when installing without
DELAYED_CHROME set.

The real problem for L10n is, that we need to use DELAYED_CHROME because of this
bug for unix installs, and DELAYED_CHROME does not work with profile installs,
as it just adds the right lines to installed-chrome.txt so that they're read and
'executed' on the following restart of Mozilla.

This means, that because of this bug
1) every unix user needs to have write permissions on the mozilla directory to
install an additional language pack
2) the user has to restart mozilla to even see the newly installed package in
preferences dialog (another restart is needed for actual switching)
3) this sometimes fails, as - for unknown reasons - there are some cases where
installed-chrome.txt isn't parsed correctly at restart, the user has to delete
chrome.rdf in this case, then everything works

Because of that, this is really annoying for L10n people. The problem is, nobody
seems to know why this is happening... :((
This bug remains on 1.0RC3.
I think this bug should be fixed or we'd have problem
spreading Mozilla 1.0 Release over the world due to 
the L10N problem.
Hugh-teh: can you confirm this bug on RC3?
Did you tested _without_ the DELAYED_CHROME switch while logged either as user
or while logged as root?
While I'm still trying to understand if this bug is defenitely gone on linux,
the l10n Traditional Chinese (Taiwan) contributor has repoted to me the
impossibility to install a lang pack either with or without the DELAYED_CHROME
switch while installing:
 logged as user
 on a Free BSD system
from the latest-1.0 build.

Could someone add in the CC of this bug someone who could deal with the *BSD tree?
I wonder if something (good) has happen in the meanwhile on the linux builds,
has not been reflected on other trees (like BSD).
Pete is a BSD person (see last comment)
There are some file issues on Asian systems that apparently started in 1.0rc3
and will hopefully be fixed in 1.0.1 -- I'm guessing that's the root of the
problems your Chinese translator found, although it's just a guess. See bug 147333
Disclaimer: I develope software but not for Mozilla (at the present;)...

I have played around with BannerBlind:
http://bannerblind.mozdev.org/installation.html

and ran across this bug.

A little research has shown what the real bug is (for my system at least, under
Debian):
It's permission denied in altering the chrome files.

I'm running debian unstable and Mozilla 1.0 and I was recieving the -225 error
(permission denied, though it never told me where, darn it).

I fixed this by doing:
cd /usr/lib/mozilla
sudo chgrp -R staff . ; sudo chmod -R g+rwX . ; sudo find -type d -exec chmod
g+s {} \;

After doing this, I got the -239 error.
I looked around and saw that component.reg was a symlink to
/var/lib/mozilla/component.reg

I repeated my commands in /var/lib/mozilla and then I was able to successfully
install the .xpi.

There are three things that bug me about this:
1) The error messages were singularly unhelpful.  After I changed the
permissions in /usr/lib/mozilla I finally got a *little* more info from
/usr/lib/mozilla/install.log (which I would never had looked at): Install
**FAILED** with error -239  --  07/31/2002 13:37:23
2) The errors are obviously not passing up from the chrome component.
3) And last, but not least by a long shot: It shouldn't be installing this stuff
to /usr/lib anyway!  I have a whole $HOME directory for this stuff, for goodness
sake, use it!

Anyway, I suspect things like the symlink to /var and stuff might be why this
wouldn't work for RPMs and such, since the FHS would require the chrome stuff to
go in var.  Though, as I mention, this stuff should all go in the HOME
directory, unless root does an install and checks a check box saying "Yeah, I
want this system wide".  Otherwise, use $HOME!

Anyway, hope this helps.

Ciao!
Blocks: 164804
This bug still exists on at least FreeBSD for recent nightly builds.
(and 1.2a release)
dveditz@netscape.com mentioned about bug 147333 (see comments above),
but that's about loading local files with non-ASCII filenames. I did
not put any non-ASCII characters in the language pack. So I guess it
is not the reason to this bug...

Christian, check the install.js of the package you're trying to install. It is
it which states if chrome should try to install the package in $HOME or not.
The normal file permission problem some of the reporters refer to truly is an
easy one to run into on unix systems. Especially when xpi doesn't report it's
intent to install itself system-wide or when user doesn't even know what that
means. Projects like http://www.debian.org/devel/debian-desktop/ try to remedy
these situations, but the installation dialog could still be a tad more
expressive, mention the install.log file for example.
Samuli Tuomola:
The file permission problem is not what this bug is really about. Comment #25
describes the problem really good. We don't fail when copying files into the
Mozilla directory, and we don't fail adding entries to installed-chrome.txt
(using DELAYED_CHROME), neither do we fail when registring the (new) entries of
installed-chrome.txt on a restart.
What we do fail with, is registering the components with the chrome registry
directly. No one's really sure why this happens.
The real downside: It still blocks us from being able to install langpacks to
the profile on unix, that's sure, and it makes unix users need an additional
restart of Mozilla when installing a langpack.
It was targeted for 1.0, that target was failed by far. We really would need
someone who can track the problem down to where it really happens, then people
would more easily be able to fix it. I'd be willing to provide a German langpack
without our DELAYED_CHROME workaround enabled, so that it should really hit the
bug, given that someone will need it for testing.
Hmm, magic happens sometimes:
I just realized that DELAYED_CHROME has stopped working on 1.3/Linux (It still
worked on 1.3b), and so I thought I'll dare to do a standard install.
The interesting part comes now: It worked, and even a profile install worked!
I now released the German 1.3 XPI pack that way, it will be interesting if
someone will start to complain about this bug again.
Actually, some changes between 1.3b and 1.3 final seem to have broken
DELAYED_CHROME but that bug seems to be magically fixed here - but I won't
believe it until it works for more people...

So please, try all your testcases etc. with 1.3 and current nightlies, let's see
if it still happens!
I believe I found one reason why this could be happening:

If I'm taking things correctly, we spit out an error -239 if we try to register
a currently used chrome registry entry again in chrome registry and probably
want to change that entry. I'm not sure if this might be the real case, but I
tried to re-install a locale pack today on a build that had already installed
that pack, and it failed when trying to register the communicator package...
-> Sean
Assignee: dveditz → ssu
some people upgrading Linky are getting this error:
http://mozdev.org/bugs/show_bug.cgi?id=3823
http://www.mozillazine.org/forums/viewtopic.php?p=89030#89030

any chance that XPI Install could get more debug info?
To add to comment 55, the -239 chrome error when upgrading from one version of
Linky to another (1.7.0) has been happening not *just* on *nix, but under Win32
as well.

From MozillaZine:

http://www.mozillazine.org/forums/viewtopic.php?p=89030#89030
this is bad... very bad. this one should be fixed.
OS: Linux → All
I can't reproduce this bug on winXP or RH8.0 with the linky tool.  I've tried
upgrading and also installing the same version.  All works fine.  Will try a few
other test scenarios.

I did find that if I only had read permissions to
.../chrome/installed-chrome.txt, it would die with -239.  The install.log looks
exactly like the one in comment #25.
I can reproduce this reliably on Firebird nightlies (Gecko/20030702 Mozilla
Firebird/0.6) installing the Linky extension. Anyone wanting further info or
debug to track it down mail me instructions and I'll send you any info you need...
The problem with linky seems to be that it is trying to register a non-existent locale. I don't have the locale "da-dk" setup on my system. So, I changed the line: 
    const myLocales = new Array("en-US", "da-dk"); // the locales available
to
    const myLocales = new Array("en-US"); // the locales available
and the install worked. 

(The script later does this:
    for (var i = 0; i < myLocales.length; i++) {
	err_tmp = registerChrome(LOCALE | PROFILE_CHROME, sysChromeUserJar, 
                  "locale/" + myLocales[i] + "/" + myProductRegKey + "/");
    }
)

I'm also not certain that "da-dk" is valid. Shouldn't it be "da-DK"?

-------------------------------------------------------------------------------
file:///M:/tmp/linky/linky.xpi  --  07/10/2003 10:44:16
-------------------------------------------------------------------------------

     Linky (version 1.7.1.20030602)
     -----

     ** Linky version 1.7.1 being installed on 2003062408
     ** Installation method is 2
     ** ok adding jar file.
     ** ok registering the content chrome.
     ** ok registering the locale chrome.
     [1/4]	Replacing: E:\Documents and Settings\GCoakley\Application Data\Mozilla\Profiles\default\lr5x4i5v.slt\chrome\linky.jar
     [2/4]	Register Package: jar:file:///E:/Documents%20and%20Settings/GCoakley/Application%20Data/Mozilla/Profiles/default/lr5x4i5v.slt/chrome/linky.jar!/content/linky/
     [3/4]	Register Locale: jar:file:///E:/Documents%20and%20Settings/GCoakley/Application%20Data/Mozilla/Profiles/default/lr5x4i5v.slt/chrome/linky.jar!/locale/en-US/linky/
     [4/4]	Register Locale: jar:file:///E:/Documents%20and%20Settings/GCoakley/Application%20Data/Mozilla/Profiles/default/lr5x4i5v.slt/chrome/linky.jar!/locale/da-dk/linky/
     ** Problem performing install. Error code: -239
     ** Problem installing. Error code: -239. Error codes can been seen at: http://devedge.netscape.com/library/manuals/2001/xpinstall/1.0/err.html

     Install **FAILED** with error -239  --  07/10/2003 10:44:31
Removing "da-dk" from that array does the trick for me too, with Firebird 0.6. 
(Thanks.)
Just tried to install locally (in-profile) and it worked after I changed da-dk
to da-DK. It seems the parser may be missing a call to or two to tolower() or
equivalent. I'm sure locale names should be case-insensitive. (or are they?)
This is happening on FreeBSD with: Mozilla/5.0 (X11; U; FreeBSD i386; en-US;
rv:1.5a) Gecko/20030731 Mozilla Firebird/0.6.1

The strange thing is, I have the same browser (built from the ports collection)
at home, and there the AdBlock install _was_ successful.

Also, the .jar file is not actually placed anywhere. 

-------------------------------------------------------------------------------
http://adblock.mozdev.org/adblock-firebird-0.3.xpi  --  08/04/2003 10:58:28
-------------------------------------------------------------------------------

     AdBlock (version 0.3)
     -------

     [1/2]      Installing: /usr/home/drwilco/.phoenix/default/xybwlyf0.slt/chro
me/adblock.jar
     [2/2]      Register Content: jar:file:///usr/home/drwilco/.phoenix/default/
xybwlyf0.slt/chrome/adblock.jar!/content/

     Install **FAILED** with error -239  --  08/04/2003 10:58:29


This fixed the unexplainable -239 error when installing the AdBlock extension.

Lines 247 - 254 depend on NS_SUCCEEDED(rv) being true before entering that
block, but rv is not initialized to anything before there.
Attachment #129229 - Flags: review?(ssu)
Comment on attachment 129229 [details] [diff] [review]
patch for mozilla/xpinstall/src/nsRegisterChrome.cpp

r=ssu

great job DocWilco!

Here are DocWilco's comments on how he figured this out:
=======================================
Yes this patch fixed the problem for me at work.

It was a tough one to crack, because at home I didn't have the problem at all.
But diff version of FreeBSD and diff version of GCC might have something to do
with that.

I started out adding fprintf()s everywhere where CHROME_REGISTER_ERROR (or
whatever the define for 239 was) was used. Adding them with else blocks to all
the if's. That did make it any clearer, so I then added  "if(NS_FAILED(rv))
fprintf("bla %d %s", __LINE__, __FILE__);" right after any use of rv that might
change its value.

That showed me that rv contained an error on line 249 already, and after adding
debug fprintf()s in the chrome lib I found out that InstallSkin on line 428
wasn't even called. So rv contained an error, even though it hadn't been
assigned any value yet. Causing the if statements on 250 and 253 to short
circuit. 

Setting rv to NS_OK at the declaration did indeed fix that, and AdBlock stopped
failing to install (and I'm using it on that machine with success). I can't see
how my change would have a negative impact either, since it makes good on the
assumption that's made on lines 250 and 253.
Attachment #129229 - Flags: superreview?(dveditz+bmo)
Attachment #129229 - Flags: review?(ssu)
Attachment #129229 - Flags: review+
Sean: could you also check it in, since I dont have cvs access
sure, I can check it in once all the reviews are done.
Status: NEW → ASSIGNED
Comment on attachment 129229 [details] [diff] [review]
patch for mozilla/xpinstall/src/nsRegisterChrome.cpp

sr=dveditz

We should consider this simple and safe fix for 1.4.1
Attachment #129229 - Flags: superreview?(dveditz+bmo)
Attachment #129229 - Flags: superreview+
Attachment #129229 - Flags: approval1.4.x?
patch checked in to trunk only.  Thanks DocWilco for the patch!
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 129229 [details] [diff] [review]
patch for mozilla/xpinstall/src/nsRegisterChrome.cpp

a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #129229 - Flags: approval1.4.x? → approval1.4.x+
patch checked in to MOZILLA_1_4_BRANCH.
Keywords: fixed1.4
Keywords: fixed1.4 → fixed1.4.1
I just got this error again using Firebird 8/16 under XP trying to install Linky
1.7.1.  I need to either reopen the Linky bug
(http://mozdev.org/bugs/show_bug.cgi?id=3823) or this bug, depending on if it's
a browser bug or a Linky bug.  Opinions?
Confirming that it is (was) definitely Linky's fault, not this bug.  The latest
version (2.0.0) works just fine without a -239 error.
Even with Linky 2.0.0 I've seen the -239. I'm currently not able to reproduce,
but I'll open a new bug if I can found out why. So it's not 100% Linky's fault.
Do you install addons in your profile directory or globally? Is this triggered
by installing addons in your profile directory, after you've first installed it
globally or vice versa? 
I cant really remember. I just got -239 every time I tried to install. I'll have
to investigate
Not a patch meant for the trunk, but for people trying to figure out why
they're getting a -239. It will help narrow things down a little with some
extra output in install.log.

When I have a little time I will improve it some (there's plenty of room for
it).
that patch would be great to check in. Generating the -239 is very difficult. So
checking in a patch like this would be great. please open a bug and attach the
bug and let's see if we can get a r=, sr= and checkin.
Please CC me on the new bug.
I opened a new bug. See bug 221994
Blocks: 224532
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: