Feature tracking for XPInstall UI. Includes a review of existing UI, respecification if required, and required code modifications to fit specification. Classifying this as "Downloading" since there may be some dlmgr unification potential.

I made a lot of suggestions about the XPI dialog and the downloading-executable dialog (which IMO should be the same) in bug 91969 comment 72.

I'm not sure if this is because of the way different extensions are written, but there should be a set standard for the Cancel/OK Buttons for which installs to the profile and which installs to the app directory. Without closely reading the dialogs for each extension, it is too easy to put an extension in the wrong place because you have become accustomed to clicking a certain button to install to the profile/app directory for most extensions. This is one of the biggest annoyances I encounter when creating a new profile and installing all the extensions, since I want all of my extensions to install in the profile. But if I don't read carefully, the extensions are scattered between the profile and the app directory. If there was a set standard, it would take much less time to get the desired extensions installed on a new profile or a new version of Firebird.

adding dependency.

I completely agree with comment 2. In fact, the extension itself shouldn't be the one asking about where to install itself (profile/app folder), that should be the responsibility of Firebird. Maybe that doesn't belong to this bug but to Hyatts extension rewrite plans.

I agree with #2 as well; However, I also think it should be mandatory that extensions provide the option, no matter where the buttons are - as some do not, leaving you with no control over where it ends up, which is certainly not a good thing.

Another thing I have noticed is that some extensions seem to only offer they option of where to install on Windows, and not Linux. This may be my particular installation, although I doubt it since some extensions provide the option on both Linux and Windows, but this is another reason that Firebird itself should handle the choice of location for an extension.

Yeah I know this is annoying. Some of this is the extension author's lack of knowledge/laziness, some of it is our inflexible API I'm pretty sure. I'm going to conduct a survey on the mz forums to find out why people are using alert()s in their install scripts. Perhaps we can find a way to streamline things.

Note that bug 226680 suggests having a global preference to decide whether an extension should go to global or user chrome. However, this might not be the ideal solution: One might want to install certain extensions for all users (to standardize the general browser experience for this computer), some others for purely personal use. It wouldn't be user-friendly if we first had to go to Tools->Options->Wherever to change the setting. So with or without the global pref option we definitely should allow a case-by-case decision. Another issue is that non-admin users don't usually have write access to the global chrome directory (unless they've installed it into their user dir). Mozilla should recognize such a situation and automatically install extensions into the user profile folder. It's not very obvious to let the user choose between Profile and Global and then fail with some techspeak-error when user chooses Global. However, if the user has write access, let him choose.

This has been fixed for 0.8... on the branch only but not on the trunk. Thus shifting to 0.9 for checkin to the trunk.

Ben, what exactly has been fixed?

In bug #232436 I put some remarks on this subject, including one completely missing here: it does not make sense to offer system-wide installation when the current user lacks write access to this directory.

That was mentioned in comment 8. What Ben 'fixed' afaik is that XPIs show up in the download manager now.

For installation of local XPI files the download manager shouldn't be used because we don't have to download any file from the web. It's an ugly side effect at the moment and disturbs the installation process.

I agree with comment #14. It's nice to see that the problems with the XPInstall system have finally been RESOLVED FIXED but the use of the download manager for the installation of local files seems hackish and unneeded. New bug?

Yes, of course. I created bug 236896 which follows my comment 13. -> QA (just to have one)

Coming soon to a Firefox near us, I hope???