Last Comment Bug 109044 - Install error -239 registering chrome on some systems
: Install error -239 registering chrome on some systems
Status: RESOLVED FIXED
[adt3]
: fixed1.4.1
Product: Core Graveyard
Classification: Graveyard
Component: Installer: XPInstall Engine (show other bugs)
: Trunk
: x86 All
: -- normal with 3 votes (vote)
: mozilla1.0
Assigned To: Sean Su
: Grace Bush
:
Mentors:
http://optimoz.mozdev.org/gestures/mo...
: 106701 111898 124809 136981 (view as bug list)
Depends on:
Blocks: 164804 224532
  Show dependency treegraph
 
Reported: 2001-11-08 06:15 PST by Pavol Vaskovic
Modified: 2015-12-11 07:21 PST (History)
34 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch for mozilla/xpinstall/src/nsRegisterChrome.cpp (367 bytes, patch)
2003-08-05 07:35 PDT, DocWilco
ssu0262: review+
dveditz: superreview+
asa: approval1.4.1+
Details | Diff | Splinter Review
debugging patch for mozilla/xpinstall/src/nsRegisterChrome.cpp (6.23 KB, patch)
2003-10-13 02:37 PDT, DocWilco
no flags Details | Diff | Splinter Review

Description Pavol Vaskovic 2001-11-08 06:15:22 PST
We are getting bug report about installation problems with latest linux
nightlies on MozGest. Doen't matter if user is root or not.

--mondo
Comment 1 Pavol Vaskovic 2001-11-08 06:23:01 PST
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
Comment 2 Pavol Vaskovic 2001-11-08 06:57:49 PST
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>
Comment 3 Jimmy Lee 2001-11-08 08:55:51 PST
Reassigning QA Contact to Grace.  See if you can reproduce this problem.  -239
is CHROME_REGISTRY_ERROR
Comment 4 Grace Bush 2001-11-09 12:20:56 PST
cannot reproduce this with Mozilla nightly build 2001110908 nor commercial trunk
build 2001110908
package loads without errors and when relaunch- Mouse gestures are working
Comment 5 Pierre Chanial 2001-11-09 20:36:59 PST
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?
Comment 6 Grace Bush 2001-11-14 10:10:03 PST
duplicate of bug 29741?
Comment 7 Pierre Chanial 2001-11-14 15:00:26 PST
I don't think so.
I tried to install mozgest as root (thus with write privileges) and the reported
error is -239, not -225.
Comment 8 Pavol Vaskovic 2001-11-15 08:00:15 PST
We have this confirmed on Solaris.
See our mozdev bugzilla: 
http://mozdev.org/bugs/show_bug.cgi?id=663
Comment 9 Neil Pilgrim 2001-11-15 14:15:03 PST
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.
Comment 10 Neil Pilgrim 2002-01-11 17:14:40 PST
Just to confirm that this is still present in 2002011021 (linux).
Comment 11 Dawn Endico 2002-01-30 16:47:57 PST
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)
Comment 12 Asa Dotzler [:asa] 2002-01-30 18:36:50 PST
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.
Comment 13 Andrea 2002-01-31 10:10:27 PST
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.
Comment 14 Andrea 2002-02-01 01:55:35 PST
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 ?
Comment 15 Matthias Versen [:Matti] 2002-02-11 10:14:37 PST
*** Bug 124809 has been marked as a duplicate of this bug. ***
Comment 16 johann.petrak@gmail.com 2002-02-11 11:03:25 PST
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?
Comment 17 Daniel Veditz [:dveditz] 2002-02-11 12:38:55 PST
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.
Comment 18 Daniel Veditz [:dveditz] 2002-02-11 12:42:01 PST
nominating, the flakiness of this problem introduces significant risk to MachV.
Comment 19 Syd Logan 2002-02-11 16:52:08 PST
required comment
Comment 20 Andrea 2002-02-26 13:41:40 PST
syd: Wich kind of comments do you need ?
How can I help you ?
Comment 21 Tsukasa Maruyama 2002-02-28 03:14:35 PST
same problem bug 106701?
Comment 22 Andrea 2002-02-28 15:22:52 PST
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).
Comment 23 Tom Mraz 2002-02-28 23:32:36 PST
*** Bug 106701 has been marked as a duplicate of this bug. ***
Comment 24 Daniel Veditz [:dveditz] 2002-03-01 12:53:44 PST
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.
Comment 25 Andrea 2002-03-02 08:16:21 PST
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
Comment 26 Neil Pilgrim 2002-03-03 13:21:36 PST
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!
Comment 27 Daniel Veditz [:dveditz] 2002-03-03 16:39:13 PST
fair enough. It's still a mystery what's actually causing the problem.
Comment 28 Brian Ryner (not reading) 2002-03-05 02:57:29 PST
not going to make 0.9.9
Comment 29 Brian Ryner (not reading) 2002-04-04 12:13:58 PST
dveditz, do you think you could take this?  I doubt I'm going to be able to make
any progress on it.
Comment 30 Daniel Veditz [:dveditz] 2002-04-04 13:52:26 PST
Damn, you win the "most doomed" contest 10 to 7 (nsbeta1+). <sigh>

I have no idea where to begin :-(
Comment 31 Georg Wild 2002-04-05 04:34:55 PST
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.
Comment 32 Pavol Vaskovic 2002-04-10 17:20:28 PDT
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
Comment 33 Daniel Veditz [:dveditz] 2002-04-11 19:29:09 PDT
*** Bug 136981 has been marked as a duplicate of this bug. ***
Comment 34 scottputterman 2002-04-22 19:41:06 PDT
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.
Comment 35 scottputterman 2002-04-22 19:57:52 PDT
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.
Comment 36 Michael Hendy (Hendikins) 2002-05-07 03:32:53 PDT
*** Bug 140662 has been marked as a duplicate of this bug. ***
Comment 37 Michael Hendy (Hendikins) 2002-05-07 03:33:17 PDT
*** Bug 140949 has been marked as a duplicate of this bug. ***
Comment 38 HJ 2002-05-07 03:54:28 PDT
*** Bug 111898 has been marked as a duplicate of this bug. ***
Comment 39 HJ 2002-05-21 06:00:40 PDT
Can you do anything with this information:
http://multizilla.mozdev.org/xpi/linux-inst-error.txt ?
Comment 40 Andrea 2002-05-23 11:10:38 PDT
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.
Comment 41 Robert Kaiser 2002-05-23 12:39:44 PDT
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... :((
Comment 42 Hung-Te Lin 2002-05-24 08:01:11 PDT
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.
Comment 43 Andrea 2002-05-24 09:50:34 PDT
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?
Comment 44 Andrea 2002-06-05 07:29:24 PDT
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).
Comment 45 Brian King [:kinger] 2002-06-05 09:26:03 PDT
Pete is a BSD person (see last comment)
Comment 46 Daniel Veditz [:dveditz] 2002-06-06 23:19:50 PDT
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
Comment 47 Christian Höltje 2002-07-31 12:11:23 PDT
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!
Comment 48 Hung-Te Lin 2002-09-16 19:11:44 PDT
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...
Comment 49 Vincent Béron 2002-10-26 15:44:30 PDT
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.
Comment 50 Samuli Tuomola 2002-12-07 08:16:02 PST
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.
Comment 51 Robert Kaiser 2002-12-19 13:57:51 PST
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.
Comment 52 Robert Kaiser 2003-03-17 08:30:52 PST
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!
Comment 53 Robert Kaiser 2003-05-11 07:30:15 PDT
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...
Comment 54 Daniel Veditz [:dveditz] 2003-05-12 10:54:56 PDT
-> Sean
Comment 55 Henrik Gemal 2003-06-02 01:50:33 PDT
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?
Comment 56 Jason Bassford 2003-06-02 05:19:21 PDT
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
Comment 57 Henrik Gemal 2003-06-02 12:24:53 PDT
this is bad... very bad. this one should be fixed.
Comment 58 Sean Su 2003-06-06 18:10:12 PDT
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.
Comment 59 Nicholas Avenell 2003-07-07 14:22:35 PDT
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...
Comment 60 Glen Coakley 2003-07-10 02:59:37 PDT
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
Comment 61 Joel Baxter 2003-07-15 14:42:53 PDT
Removing "da-dk" from that array does the trick for me too, with Firebird 0.6. 
(Thanks.)
Comment 62 Hogarth 2003-07-15 15:36:47 PDT
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?)
Comment 63 DocWilco 2003-08-04 02:30:01 PDT
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

Comment 64 DocWilco 2003-08-05 07:35:10 PDT
Created attachment 129229 [details] [diff] [review]
patch for mozilla/xpinstall/src/nsRegisterChrome.cpp

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.
Comment 65 Sean Su 2003-08-05 14:18:00 PDT
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.
Comment 66 Henrik Gemal 2003-08-05 14:38:01 PDT
Sean: could you also check it in, since I dont have cvs access
Comment 67 Sean Su 2003-08-05 14:41:10 PDT
sure, I can check it in once all the reviews are done.
Comment 68 Daniel Veditz [:dveditz] 2003-08-05 16:31:08 PDT
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
Comment 69 Sean Su 2003-08-05 16:38:12 PDT
patch checked in to trunk only.  Thanks DocWilco for the patch!
Comment 70 Asa Dotzler [:asa] 2003-08-06 11:01:25 PDT
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.
Comment 71 Sean Su 2003-08-06 16:38:51 PDT
patch checked in to MOZILLA_1_4_BRANCH.
Comment 72 Jason Bassford 2003-08-17 06:50:51 PDT
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?
Comment 73 Jason Bassford 2003-08-27 19:36:10 PDT
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.
Comment 74 Henrik Gemal 2003-08-27 22:51:39 PDT
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.
Comment 75 HJ 2003-08-27 22:59:32 PDT
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? 
Comment 76 Henrik Gemal 2003-08-27 23:04:19 PDT
I cant really remember. I just got -239 every time I tried to install. I'll have
to investigate
Comment 77 DocWilco 2003-10-13 02:37:53 PDT
Created attachment 133179 [details] [diff] [review]
debugging patch for mozilla/xpinstall/src/nsRegisterChrome.cpp

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).
Comment 78 Henrik Gemal 2003-10-13 02:44:49 PDT
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.
Comment 79 DocWilco 2003-10-13 04:50:25 PDT
I opened a new bug. See bug 221994
	 

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