272656 - If you try to install a global extension and the current user is running a session, you get the profile selection dialog

Status: VERIFIED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Joe Shaw]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0

If you try to install a global extension using -install-global-extension and the
user is currently running firefox, the profile selection GUI will pop up and
block until there's input.  If this is done in a script, it can effectively
block forever.

On Linux, this happens if you're logged in and running firefox as root.  I admit
this case isn't likely to happen, but the much more common case is if you're
running firefox as a user and then do "sudo firefox -install-global-extension
/foo/bar.xpi", because while it'll be able to install globally, firefox will
want to use your own profile.  (Think: doing "sudo make install")

In reality this probably isn't going to be a huge deal

Reproducible: Always
Steps to Reproduce:
1. Have a firefox session running
2. Do "sudo firefox -install-global-extension /foo/bar.xpi" as the user running
firefox.

Actual Results:  
Watch the profile manager pop up because the default profile is locked.

Expected Results:  
It should preferably install the extension like it otherwise would if I did "su"
and then installed it.  Otherwise it could error out, but it should definitely
not block on UI.

Comment 1

[timeless]

iirc sudo is a no no, it generally results in borked perms.

Comment 2

[Joe Shaw]

With firefox specifically, or just in general?  I've been doing it fine for 10
years or so generally, so I don't think that's it.  Either way though, does it
really matter?  Firefox is doing all the heavy lifting, and with root privileges.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

With Firefox specifically: we use $HOME to locate the user's profile directory,
and sudo doesn't reset that unless you tell it to with -H. 
-install-global-extension shouldn't be using a profile like that, etc., but I'm
not sure what the status of fixing that is.  I suspect this is a dup of the bug
to fix just that, but I can't find it at the moment.

Comment 4

[Robert Strong (they/them - no direct email)]

workaround...

run firefox and specify a temporary profile along with the
install-global-extension option.
export MOZ_NO_REMOTE=1
mkdir /tmp/bogus.profile
./firefox -profile /tmp/bogus.profile -install-global-extension /foo/bar.xpi
rm -d -R /tmp/bogus.profile

Comment 5

[Robert Strong (they/them - no direct email)]

I actually think the workaround should just be documented and this bug resolved -> wontfix. It is simpler to just install the extension by placing it extracted in the appdir/extensions directory but it should always have a chrome.manifest in case the user doesn't have write access to create one.

Comment 6

[Robert Minsk]

Comment #4 does not resolve the problem in bug 392434

Comment 7

[Robert Strong (they/them - no direct email)]

We *might* be removing these command line options in the future and instead recommend the placing of the extracted files into the appdir/extensions directory as noted in comment #5

Comment 8

[Dave Townsend [:mossop]]

We no longer support these command line options