Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; da-DK; rv:1.3; MultiZilla v220.127.116.11) Gecko/20030310 (1.3rc2) I usually install the following *xpi's : 1) MultiZilla (multizilla.mozdev.org) 2) googlebox (multizilla.mozdev.org) 3) home (home.no.net/trihand/mozilla/home/en/) 4) BannerBlind (bannerblind.mozdev.org) 5) AdBlock (adblock.mozdev.org) 6) enigmime-0.73.1-MacOSX.xpi (self-compiled) 7) enigmail-0.73.1.xpi (self-compiled) Now, my usual procedure is to install all of the above as either root or an admin user. On my production machine, I've until the release of 1.3 been running 1.2.1 with 1) 2) 4) 5) without any problems at all With 1.3rc2 only the following installs cross-user : 1) 2) 6) 7) If I install all of them as root, only root has access to all of the xpi's If I install as the default admin, the admin and root has access to all xpi's The normal users only see the previous mentioned 4 xpi's If I install Mozilla and the 7 xpi's in a user's home directory, the user has access to all 7 xpi's. This might possibly be a duplicate of one of the bugs regarding the xpi-install engine on Mac OS X, but I couldn't see which one it might be ;-)
Reporter, can you try your tests with a recent nightly MachO trunk build and see if your problems still persist? http://ftp.mozilla.org/pub/mozilla/nightly/
just tried 2003-03-24-16 : problem persists 1a) installed as root 1b) no other user has access to 3) 4) 5) 2a) installed as admin 2b) no other user has access to 3) 4) 5) 2c) root has full access to all 7 xpi's
bug still present i 1.4b (2003050714) This bug makes it impossible to install a some xpi's system-wide WorkAround: install Mozilla on a per-user basis
I had verified that under OSX, we preserve the permissions of files when uncompressing them. This started when we converted from CFM builds to MachO builds (I believe it started with 1.3). It sounds like 3), 4), and 5) might have been packaged up with the wrong permissions set. I did a little test with 3). When I installed 3), it created: -rw------- 1 ssu staff 9750 Dec 9 19:43 home.jar Then when I saved home.xpi and uncompressed it's contents, unzip saved home.jar as: -rw-r--r-- 1 ssu staff 9750 Dec 9 19:43 home.jar I then created my own .xpi file (I called it myhome.xpi) with the same contents as home.xpi as follows: 1) unzip ../home.xpi 2) zip ../myhome.xpi * When I installed myhome.xpi, home.jar was now: -rw-r--r-- 1 ssu staff 9750 Dec 9 19:43 home.jar It looks like from my test that unzip will set the permission to a+r if the permissions were originally go=-rwx. You should check with the creators of 3), 4), and 5) to make sure that they are setting the permissions correctly before creating the .xpi files. I unzipped and installed googlebox.xpi and googlebox.jar in both cases is set to: -rw-rw-rw- 1 ssu staff 53137 Mar 26 18:11 googlebox.jar which probably explains why it works for you.
This is probably an evangelism bug.
Does not block bug 197105 which is a meta bug for XPInstall issues on Mac OS X specifically relating to loss of functionality resulting from the CFM -> Mach-O switch.
No longer blocks: 197105
Theres something more in play here... when packaging my toolbar I initially used the "stock" jar from the command line on OS X. While all permissions were set properly on the initial files before they were packaged they seem to have gotten lost somewhere in the jar process. (resulting with installs that placed filse with either -rw------- or -r--------) I ended up packaging with winzip on my win2k box instead cause it worked the first time I tried it. not saying this isn't an evangelism issue, just think things need to be flushed out a bit more first.
OK - based on comment #4 the fix/workaround for this ought to be : 1) install the *.xpi's you want to use 2) cd <folder-path>/Mozilla.app/Contents/MacOS/chrome 3) sudo chmod 664 *jar Course of action : 1) take contact with the authors of 3), 4), 5) and have them take a look at this bug
You need to log in before you can comment on or make changes to this bug.