[MachO] not all xpi's get installed for all users

NEW
Assigned to

Status

16 years ago
3 years ago

People

(Reporter: mozilla, Assigned: ssu0262)

Tracking

Other Branch
PowerPC
Mac OS X
Bug Flags:
blocking1.4 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; da-DK; rv:1.3; MultiZilla
v1.4.0.2) 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)

Updated

16 years ago
Blocks: 197105
(Assignee)

Comment 1

16 years ago
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/
(Reporter)

Comment 2

16 years ago
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
(Reporter)

Comment 3

16 years ago
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
Flags: blocking1.4?
(Assignee)

Comment 4

16 years ago
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.
(Assignee)

Comment 5

16 years ago
This is probably an evangelism bug.

Comment 6

16 years ago
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

Comment 7

16 years ago
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.
(Reporter)

Comment 8

16 years ago
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

Updated

16 years ago
Flags: blocking1.4? → blocking1.4-
QA Contact: agracebush → xpi-engine
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.