Closed
Bug 47805
Opened 25 years ago
Closed 7 months ago
XPInstall confirm dialog needs 'Save file as...' option
Categories
(Core Graveyard :: Installer: XPInstall Engine, enhancement, P3)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: gabriel, Unassigned)
References
Details
(Keywords: helpwanted)
The 'items to install' box only has two options: 'Install' and 'Cancel'. There
should also be a 'Save file as...' option.
This is important, since there is a file on x.themes.org (Mozbilla theme) which
has a .xpi file, which is actually a renamed .zip file. (See the comments
attached to that theme).
People should also have a chance to review downloaded .xpi files before
committing to install them.
workaround: You can still right click on the click and save/as. But this is
definatly an issue, but not major, remarking to normal, and confirming.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Right clicking doesn't work on x.themes.org, because the install is triggered by
pressing on a button.
Comment 4•25 years ago
|
||
This is something we wanted to do, but will not likely have time in the near
future. The UI might be a little tricky because that dialog actually supports
multiple downloads at once. Should the "Save As..." button only apply to a
selected package? Should the modal file-save dialog come up once for each file
on the list? Unfortunately marking "Future" for now, but I *will* look at it
after I'm done with 6.0 (i.e. probably in time for "Mozilla 1.0"). Meanwhile
I'll flag this as helpwanted, and CC Blake in case he's interested.
I do not apologize, however, for doing the wrong thing if someone masquerades a
plain zip archive as a .xpi file, just as no one in their right mind would
expect an mp3 file to work if it were given a .gif extension and MIME type.
Yes, I understand what you are saying about renaming zip files to xpi files.
However, I still think people should be given a chance to look at what they are
installing before they install it. Perhaps you could pop up a dialog(ue) saying
something like "Packages may contain multiple files - please choose a directory
to download them into", and then let them just pick a directory and download all
the files into it.
Comment 6•25 years ago
|
||
I don't want to arbitrarily unpack .xpi files: the way the files end up on disk
after the installscript runs may have little to do with the structure in the
archive.
I think the ability to download the file as-is for people to examine using
their own zip tools is a fine idea, leaving the install package intact so they
can run it later if they are happy with how it looks.
Yes I agree, but I thought you said there were multiple files. If there is only
one file, it should be downloaded normally as you suggest.
Comment 8•25 years ago
|
||
I meant that a web page can install several packages at once, for example a
Mozilla update page might launch browser.xpi, mail.xpi and chatzilla.xpi all at
once, so the dialog would show those three items. If you clicked "Save As..."
we'd have to show three separate save dialogs.
Another option might be to only let you select the destination directory and
preserve the file name (do we have such a directory picker dialog already?
I don't want to have to write it ourselves), perhaps giving people a "Do you
want to overwrite?" prompt if a file with that name exists and bring up the
standard file save dialog only if they cancel from that.
Hm, that flow wouldn't be too bad. That leaves the question of how does the
user cause those files to act as an installer now that they're local. Since
we're based on MIME types I don't think you can click on a local file and have
it launch as an install. It would be nice it if did, though.
Well, people should be told that if they download files then they won't be able
to install them. I would expect only advanced users would choose to do that
anyway, so I don't see it being a problem.
Comment 10•24 years ago
|
||
*** Bug 52908 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
Shortened summary to fit in the box and on query lists without truncation.
Summary: Software install dialogue should have 'Save file as...' option → XPInstall confirm dialog needs 'Save file as...' option
Comment 12•24 years ago
|
||
I was going to submit a separate bug for Mac, but found this one and will add
my comments here. At least on Win and Linux, there is a "Save Link As"
right-button option, so a .xpi can be saved that way. No such option on Mac, and
the popup that worked in 4.x isn't working on 6.0. Also in 4.x, one simply could
drag it to the desktop.
Comment 13•24 years ago
|
||
The right-click "Save link" option only works if you can get a direct link to
the .xpi file. If the install is launched via a button's onClick handler this
may be hard to get to.
If there's a missing menu option on the Mac is has nothing to do with
XPInstall and would affect any file type. You *should* file a separate bug for
that.
Comment 14•24 years ago
|
||
Looked into this further and found that control-click on a file name will
display the Mac context menu in 6.0, which includes "Save Link as" option. Files
can be saved that way. The 4.x time delay method for making the menu appear no
longer works. As for dragging the file to the desktop, Mac behavior is now the
same as Windows which saves the link to the file.
Comment 15•24 years ago
|
||
Voting for this bug. The problem with the mozbilla theme is really irritating.
Re: installing xpi packages locally (from "Additional Comments From
dveditz@netscape.com 2000-08-10 14:58") , it can be done. I regularly download
talkback.xpi at home and install it off my local HDD since XPInstall sucks over
a modem connection.
Updated•23 years ago
|
Comment 16•23 years ago
|
||
*** Bug 150454 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
I often download XPIs before I install them, especially MozDev extensions like
MultiZilla, Bannerblind, Mozgest etc. because they might not work. Installing
the downloads is as simple as Drag&Drop onto a Mozilla window or starting from a
directory browsed with Mozilla. The problem is that some extensions have no
download link but only a "#" link with an onClick call behind (InstallTrigger).
I can't get those XPIs easily with Mozilla because the install dialogue has no
"Save as..." (this bug); instead I have to search the source code (JavaScript
functions) for the file name and download it with another program such as
Internet Explorer because Mozilla again only lets me /install/ it if I paste the
file URI into the location bar. :-( OK, I could write a small HTML page
containing the link everytime, but that is not very comfortable...
Suggestion: Implement Save As when a single XPI is to be installed and let the
user choose a folder to download to when there are multiple XPIs. You can find
such a choosing dialogue in MailNews with mails containing attachments
(right-click, choose "Save All..."). Finally, handle existing files as suggested
by deveditz. Opinions?
Comment 18•23 years ago
|
||
*** Bug 162462 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
*** Bug 164320 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
As a trivial and quick workaround I suggest to put the URI in a readonly edit
box so at least you can copy that URI and download it with wget or what ever.
See also my bug #164320 which has just been marked dupe.
Comment 21•22 years ago
|
||
*** Bug 170271 has been marked as a duplicate of this bug. ***
Comment 22•21 years ago
|
||
Comment #20 is now implemented with the new UI for installing extensions. you
now get the URI which you can copy and put in your external download manager. So
its better than it was, but still a button would be pretty nice.
Updated•19 years ago
|
Assignee: dveditz → xpi-engine
Status: ASSIGNED → NEW
QA Contact: jimmykenlee
Comment 23•17 years ago
|
||
This seems like a good potential feature -- I was just wishing for something like this in Firefox 3/3.5. It'd be useful for third-party extensions that might only offer the XPI if it's requested via a form, and reject URL copying/pasting like the current workaround.
Updated•15 years ago
|
Assignee: xpi-engine → nobody
QA Contact: xpi-engine
Assignee | ||
Updated•9 years ago
|
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•