Closed Bug 334527 Opened 18 years ago Closed 15 years ago

-install-global-extension should ignore the "show profile manager" option

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mkaply, Unassigned)

References

Details

Currently if you use -install-global-extension and have multiple profiles, the profile manager will display even though it is not needed.

global extension installs should happen with no interaction from the user.
When you found this did you already have the application running? If so, this would be bug 272656.
Nope, Firefox was not running.
I'm not able to reproduce. Just to confirm that I am using the same steps... I have multiple profiles, the account I am running as has access to all of the profiles, and verified firefox is not currently running on the system.
If you have the application set to ask for a profile on startup this will happen... perhaps that is what is happening in your case?
You are correct.
Summary: -install-global-extension should not invoke the profile manager → -install-global-extension should ignore the "show profile manager" option
There is a workaround for this in bug 272656 comment #4
can't it just be fixed by checking the command line for this param and if it is set, don't bring up the profile manager?
It may be possible to do so in the code that brings up the profile manager when in this state. It might be cleaner to provide a method for specifying that a command line handlers doesn't require a profile so they can specify this.
It appears that -silent -setDefaultBrowser has the same problem. This bug should probably be changed to be about generic handling of command line args that shouldn't require a profile or a new bug created for the proper component.
Unfortunately, that's not a good workaround since it would be different for every platform...
How are you finding the path to the binary for each platform in order to launch the app with the -install-global-extension flag?
I'm doing anything programmatic at this point. 

My problem is that I can't simply tell people to use -install-global-extension in a multiprofile case, since they might get different results.

I think we agree that the behavior is wrong, right? Why are we discussing workarounds vs. attempting to fix?
-install-global-extension was added because there was no way to install a global extension in 1.0 and other dependencies were not considered when it was implemented. A prime example is what you see in this bug as well as in the case of bug 272656. For this to work as you'd like changes would have to be made to how startup is handled and quite possibly elsewhere as well. Now there are other methods available to install a global extension such as extracting into a directory name with the extension's id in the extensions directory as well as dropping the xpi into the extensions directory. Both of these work for extensions in both the profile and the app directory but they do require write access to the directory during install... in the case of extracting into the a directory named with the extension's id write access isn't needed if the extension provides a chrome.manifest.

Another example of where this is sucky is on Linux where it requires x to be running to install the extension since the application requires x to be running. I agree the current behavior sucks but I also don't care much for trying to improve -install-global-extension. I think there are better ways to support installing extensions but using the application and -install-global-extension is always going to be prone to issues as seen in this bug.
This also affects -setDefaultBrowser - filed bug 354994
Product: Firefox → Toolkit
These options are going to be removed by bug 396510
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.