236907 - XPI download dialog does not stay after download; problematic on fast connections

Status: RESOLVED INVALID

(Toolkit :: Downloads API, defect)

Description

[A.P. Marijnissen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040227 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040227 Firefox/0.8

When using a system-wide installed browser (phoenix/firebird/firefox) that's
been installed as root (eg. in /usr/lib/mozilla-firefox/...), it's nigh
impossible to get new extensions installed in your .profile directory if you're
on a fast (7mbit+) connection.

The problem is that the actual download-dialog that presents the [Clean up] and
[Options] buttons (if the .xpi provides one), only is shown _while_ the download
is still running. Once the download is finished, it dissapears automatically
without a way to get back to it.  

Reproducible: Always
Steps to Reproduce:
1. Go to "Tools->Options->Extensions->Get New extensions"
2. Select one from the web-page (texturizer.net)
3. Click on the "Install now" button
Actual Results:  
The "Downloads" dialog is shown (note: this is NOT the download manager... it's
.xpi specific). Following soon after is the "Installation Complete" dialog-box,
saying "Software installation is complete. You will have to restart FireFox for
changes to take effect."
Note that the time between these two events is _less_ than a second if you're on
a fast line and the .xpi in question is rather small.

Note that this means that you do NOT have time to actually click on the
"Options" button in the "Downloads" dialog that'd allow you to change any
options (like "Do you want to install to your profile directory instead of your
browser directory").

This means that, if your browser-dir is a system-owned directory, the
installation will fail (after it's told you that the "Software Installation is
complete.". Once you click "Ok" on that dialog, for some .xpi's that install to
browser-dir by default, it'll pop up a message saying that you should have
permissions on your browser-dir before it'll work.
Ofcourse, the whole idea behind /usr/lib/mozilla-* on unix-systems is that users
cannot/should not be able to write to them.


Expected Results:  
Multiple ways of handling this could be available.

One option (ugly) is to ALWAYS pop-up the options-box for the .xpi it's
installing after the download so that a user is always required to review it's
options.

A better option (IMO) would be to show the "Downloads" dialog even AFTER the
download has finished and provide a "continue" button to proceed to the next
step. This will allow anybody to have the time to see what's going on and review
their options or press [clean up] or whatever.


This bug is probably only really critical in the case of browsers having been
installed as a system-app (e.g. under linux, from a distro-package) and where
the user is on a fast connection (or the file is just really tiny).

However, it is my oppinion that it'd be reasonable to provide anybody the
time/opportunity to review their options before the dialog winks out of
existence forever.

The problem is made worse by the fact that if you "missed your chance" the first
time the dialog was presented, re-trying a  failed .xpi installation will be
impossible until you've cleared the browser-cache first. When it's loaded from
cache, the display-time is infitessimal, regardless your connection-speed.

Comment 1

[Michael Hendy (Hendikins)]

-> Firefox/Downloading

Comment 2

[A.P. Marijnissen]

Additional note:
I found that some .xpi's do perform the "Always popup the options-dialog after
downloading" like i suggested as a "ugly solution".

However, some (most?) .xpi's do not show this behaviour. "Live HTTP Headers" is
one extension that I've encountered (and tried to install Many many many many
times) that doesn't ask you where it should be installed _unless_ you press the
options-button during the download.

As such the "Live HTTP-headers" .xpi is a good test-case for this bug.

URl for this extension on texturizer.net is:
http://downloads.mozdev.org/livehttpheaders/livehttpheaders.xpi

HTH.

Comment 3

[A.P. Marijnissen]

Note number two (from original bug-submitter):

I just found out that the "Extensions Download" dialog with the "[options]"
button that i couldnt click, is actually the new and improved download manager.

My assumption that under "options", the .xpi's would present the option "install
in profile directory" is in error because it turned out that it "happened like
that once", where it was downloading the file, completed and provided such a
dialog just after i had pressed that "options" button.

It turns out that:
-  THIS particular extension (Image Zoomer) had a dialog built in (at
install-time) that asks wether or not you want it in the profile dir or
somewhere else... 
_and_
It turns out that the Live HTTP headers DOESNT have this kind of dialog built in
_and_ it turns out that the download dialog for extensions "doesnt exist" since
it's the standard, improved, download manager that pops away when the download's
finished (in the default setting)

In other words, my bug-request is invalidated because of this reason.
However, the problem still stands that some .xpi's simply dont ask "where you
want them". 

I've learned, already (while searching through similar bug-reports before
posting this one) that:

- In the past people have discussed this same issue
- In the past there was an issue where some components couldnt be run from the
.profile dir preventing some extensions from being installed in .profile in the
first place
- These issues have been adressed (partly or entirely... i do not know which)

The fact is, there's still extensions out there (important ones, too!) that
don't ask where you want to install them.
I've meanwhile managed to install live http headers into my .profile dir and run
it from there... which means that at least for THAT extension, the limitations
on running stuff from .profile isnt currently an issue anymore.

As such, my bug-report can be summed up with:

There are .xpi's that should be fixed to have them ask the user if they are to 
be installed in profile-dirs or in system-dirs.
These .xpi's should be fixed in cases where there's no reason they shouldnt be
installable in .profile dirs.


Sorry for the mess .... X.x

Comment 4

[Ali Ebrahim]

Reporter, are you using the Debian mozilla-firefox package? If so, what hardware
are you running on (since you've selected "Other")?

Comment 5

[A.P. Marijnissen]

Sorry.
Using it on PC-hardware (Debian Unstable on PIII machine)

Comment 6

[Ali Ebrahim]

--> PC

Reporter is using the mozilla-firefox Debian package, version 0.8-3.

Comment 7

[Ali Ebrahim]

We have a new extension system in Firefox 0.9. Please reopen if you're still
having the same issue with that.