214260 - XPInstall UI

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 1

[Jesse Ruderman]

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.

Comment 2

[Robert Parenton]

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.

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

adding dependency. 

Comment 4

[David Tenser [:djst]]

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.

Comment 5

[Andrew Keyser]

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.

Comment 6

[Robert Parenton]

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.

Comment 7

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 8

[Jens Bannmann]

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.

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 10

[David Tenser [:djst]]

Ben, what exactly has been fixed?

Comment 11

[Marcin Kasperski]

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.

Comment 12

[alanjstr]

That was mentioned in comment 8.

What Ben 'fixed' afaik is that XPIs show up in the download manager now.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 14

[Bradley Chapman (not reading bugmail, still gone but not forever)]

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?

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Yes, of course. I created bug 236896 which follows my comment 13.

-> QA (just to have one)

Comment 16

[David A. Cobb]

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