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.
Component: Installer: XPI Packages → Downloading
Product: Browser → Firefox
Version: Trunk → unspecified
Assignee: xpi-packages → bugs
QA Contact: aebrahim
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.
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
Reporter, are you using the Debian mozilla-firefox package? If so, what hardware are you running on (since you've selected "Other")?
Sorry. Using it on PC-hardware (Debian Unstable on PIII machine)
--> PC Reporter is using the mozilla-firefox Debian package, version 0.8-3.
Hardware: Other → PC
We have a new extension system in Firefox 0.9. Please reopen if you're still having the same issue with that.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.