User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 Since bug 12561 is fixed, extensions creators can decide to provide installation to profile directory. But default installation still goes to the mozilla tree - which causes no extension to be installed into profile dir at the moment - except for themes and might be language packs (which I didn't try). As of the new roadmap extensions will become much more important than they are now, the mozilla suite will get hardly usable on Unix. Installing extensions with root permissions is bad, because (the following arguments are taken from an article in n.p.m.seamonkey): ============= - Extensions in your profile dir do not alter the Mozilla executable at all. - Starting complex applications like mozilla as root is a security risk. Starting it with extensions of untrusted origin is bad. And you have to start mozilla in order to install extensions. - Plugins and themes can be installed on a per-user base. Why can't extensions? - On multi user systems (like companies and universities) the admin has to care on extension installation. This causes much work for him/her. - It is even possible today to install extensions in your profile dir, if the creator of that extension makes it possible. What I am asking for is to make this behaviour the default behaviour, because most extension creators don't care for permissions on unix systems. ============= I don't know, how permissions are handled with Windows XP and MacOS. If there are the same issues, OS should be set to ALL and summary should be adjusted. Reproducible: Always Steps to Reproduce:
ACK. Without this addons are not usable at all. Might even be critical. pi
Status: UNCONFIRMED → NEW
Ever confirmed: true
ccing some people who would actually be implementing this, as well as interested parties... Agreed that this is nearly a must-have for a decent extension mechanism on Linux.
FWIW, I heard Multizilla tried installing to the profile directory for some builds early in 1.4, and people disliked it (see http://www.mozillazine.org/forums/viewtopic.php?t=8678). If these objections to profile only install are valid (I have no I idea what the objections are), it might be best if Mozilla provided an install dialog along the lines of: Installing extension blah. Do you wish to make this extension avaliable in the current profile only or in all profiles on your system? [Install in this profile] [Install in all profiles] rather than leaving the extension author to provide the options. Obviously if Mozilla could determine that the mozilla tree chrome directory was not writeable, it could just go ahead and install to the profile directory. In any case I agree that installing to profile by default is better, regardless of whether the system enforces permissions on the mozilla directory or not - therefore the OS should be all.
I agree with James. Checking permissions is essential. Right now Mozilla even says, that installation was successful when it failed badly. Further, I don't think, that an addon should decide or even suggest where it likes to be installed. So the choice James suggested is a good one, if available. pi
OS: Linux → All
If you want to install globally, and Mozilla detects that doesn't have write permission there, I believe it should ask for the root password and call an install process (and only that install process) as root, doing the global install there. Users that fear it's bad to let Mozilla call anything as root, might just cancel the dialog when it asks for the password, stating what it needs it for and that this might be dangerous.
There is the second question here. How does the sysadmin install extensions without launching Mozilla as root?
KaiRo: This bug is not on global install. It is the request to make local install the default behaviour, or at least to let the user (not the extension maker) decide. If global install is default behaviour and there is no (easy) possibility for the user to change that, extensions become unusable for many users who want to use extensions. The main reasons are a) security awareness b) no knowledge of the root password (multi user systems - companies and universities) c) easy upgrade of mozilla without installing all extensions new. While c) is not very important as many extensions may be broken with new versions, a) and b) make extensions unusable on many systems. And, as stated above, there is no reason why plugins can be user-installable but estensions can not. IMHO is your request for a root password question another bug, enhancement in this case.
*** Bug 203750 has been marked as a duplicate of this bug. ***
Some pluggins, when installed as root, use permission 600 for all of their files which means that user's can't read the pluggin. When mozilla 1.5 running as a user encounters one of these pluggins it silently hangs when trying to load, without popping up any dialog box. When run again (as a user would if they didn't know to look for the lock file) it brings up the profile selector and tells the user that the profile is already in use but doesn't offer any explanation. Installing the pluggins in the users directory would fix this, but Mozilla should also fail gracefully (or at least with a visible error message) when it encounters chrome it can't read.
William: This bug is not on plugins. I'm not sure if you chose the wrong term and meant extensions, but even in this case it would be good to open a new bug.
Changing summary, as this applies also to at least Mac OS X
Summary: Make extensions usable on Unix/Linux - extensions should be installed in profile dir with user permissions per default. → Make extensions usable - extensions should be installed in profile dir with user permissions per default.
The according firefox bug is bug 204049.
FIXED due to moving to the toolkit addons manager.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.