User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b2pre) Gecko/2008011409 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b2pre) Gecko/2008011409 Minefield/3.0b3pre Bug #311008 adds a default "system install" location for extensions. However, it would be nice for developers to be able to override this. For example the "jhbuild" system allows compiling a lot of software in a separate filesystem prefix, and ideally a jhbuild-ed mozilla would pick up jhbuild-ed Firefox extensions. Something like MOZ_SYSTEM_EXTENSIONS_PATH or the like. Reproducible: Always

Would take a patch here I think, but not going to actively work on it.

This patch: - provides ability to override system extension path (/usr/lib/mozilla/extensions) by MOZ_SYSTEM_EXTENSIONS_PATH environment variable - adds new extension directory specified by MOZ_EXTENSIONS_PATH environment variable

Comment on attachment 381064 [details] [diff] [review] patch Can you please review this one?

I had read this request as talking about changing the system install locations at compile time, not at runtime using environment variables. And I don't think we want to add yet another install location at this time. Copying in bsmedberg for his input.

The environment variable gives us flexibility to define extension directory in firefox shell startup script. By this, we can register extensions regard to the current system state (e.g. current language).

Hm, it seems better to me to do the language-extension association you're talking about in the core code. If the firefox startup script is setting this variable, then it isn't useful for the developer case I was talking about originally (jhbuild scenario).

Actually, I was hoping this could take something like a colon-separated list instead of just one dir, which would indeed help solve your case Colin.

Ok, if the startup script extended the variable rather than overwrite it (something like MOZ_EXT_PATH="${MOZ_EXT_PATH}:/usr/lib/firefox/$LANG/" that would work. But it still seems cleaner to me have the language work done in the code rather than the startup script.

(In reply to comment #7) > Actually, I was hoping this could take something like a colon-separated list > instead of just one dir, which would indeed help solve your case Colin. Yeah, that was my first plan and I'm willing to prepare such patch if there's a chance to get it into tree.

There is an updated one. Extension directories are get from MOZ_EXTENSIONS_PATH system variable as a normal directory list like plugin dirs.

Comment on attachment 381746 [details] [diff] [review] v2 with directory list Configuring install locations based on environment variables is not something we want. If nothing else it opens a can of worms where I know there are bugs

Clarifying the bug summary, though whether the build guys would even be ok taking an additional flag to control this I don't know. It seems more easily solved with a small patch.

(In reply to comment #12) > Clarifying the bug summary, though whether the build guys would even be ok > taking an additional flag to control this I don't know. It seems more easily > solved with a small patch. Which part? There are two separate issues here. * An environment variable for developers who are building Firefox into separate buildroots, and want it to be able to pick up extensions from inside that buildroot (right now /usr/lib/firefox is hardcoded I believe, even if a different --prefix is given). An example of this is say the Beagle Firefox extension. * An implementation means for locale-specific extensions

(In reply to comment #13) > (In reply to comment #12) > > Clarifying the bug summary, though whether the build guys would even be ok > > taking an additional flag to control this I don't know. It seems more easily > > solved with a small patch. > > Which part? There are two separate issues here. About what the original summary was about, being able to change the default system install location for extensions. Nothing about locales specific extensions.

(In reply to comment #11) > (From update of attachment 381746 [details] [diff] [review]) > Configuring install locations based on environment variables is not something > we want. If nothing else it opens a can of worms where I know there are bugs If a security is the issue here, we can place the extension directory origin to current firefox installation dir and the env variable will point to a subdirectory here. Like "/usr/lib/firefox/" + $MOZ_EXTENSIONS_PATH. It should sort out all sec. issues, if the attacker has a permission to write to firefox install dir, he/she can install any extension anyway. And we can restrict dirs like ".." and "~".

Due to a long period of inactivity on this bug (6.85 years), I am intending to close this bug within a month or so in accordance with: https://wiki.mozilla.org/Add-ons/OldBugs Please remove [intent-to-close] from the whiteboard and comment on this bug if you would like to keep it open.