Download Manager no longer let's you define where .zip's are saved

RESOLVED WORKSFORME

Status

SeaMonkey
Download & File Handling
RESOLVED WORKSFORME
15 years ago
12 years ago

People

(Reporter: Micheal, Assigned: Blake Ross)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

When downloading a .zip file, Download Manager no longer let's you define where
to save said files. On my system, it automagically saves it to C:\Documents and
Settings\Micheal\Local Settings\temp\ which is not what I want. Everything else
it seems is okay. For example, *.tar.gz files are definable. A box pops up and
asks where I want to save the file. This was the case for everything in 1.2.1 if
I remember correctly.

Reproducible: Always

Steps to Reproduce:
1. Click on a .zip download
2. Wait for it to download
3. You will see no save box pops up

Actual Results:  
Mozilla saved the .zip file to the temp directory.

Expected Results:  
Mozilla should have popped up a save box, asking where to save the file.

Comment 1

15 years ago
This works for me, using Mozilla 1.3 (Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.3) Gecko/20030312) on Windows 2000.
(Reporter)

Comment 2

15 years ago
Then a bug with the XP build?

Comment 3

13 years ago
WFM with Moz 1.7.3 on WinXP. Reporter, do you still see this problem with the
latest nightly (or even 1.7.3)? If not, this bug has probably been fixed and can
be closed. Thanks.
Product: Browser → Seamonkey

Comment 4

13 years ago
There's a regression. Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5)
Gecko/20041122 (and 1.8a4), there are several file download problems occurring
that were supposed to be fixed.

A long-standing complaint of mozilla downloading was that it downloaded into a
temp directory generally with a random filename, instead of downloading the file
into the user-specified directory with the user-specified filename. I thought
this was fixed around versions 1.4, 1.5 or 1.6. I think this is working OK with
version 1.7.3 though I will test that later today after yanking 1.8a5 off this
system. The solution that was working was that the download would start in a
temp directory and then the partial download would be moved to the permanent
directory as soon as the user entered the info. Remember? This worked good. And
somebody changed it. One of the things that can go wrong is that the temp
directory may be on a partition that runs out of space.

One can now specify where the final destination of a zip file is, but you can't
make it go there to start with. And if your download is interrupted, you've got
a partial download in the temp directory with a random name (though the
extension is preserved) and no clue as to what it's supposed to be. I don't know
if 1.8a5 will resume such downloads, but I'd be surprised.

Suppose it's not a zip file or other file that's a filetype known to your
system. Then the file automatically goes into the temp directory, with no way
for the user to specify where he or she wants it. It also gets saved with a
random name, and when the download is done, tells the operating system to open
it---as if the operating system knew what to do with an unregistered filetype in
the first place. I've seen this behavior with (floppy) .img files and with .bin
files that are chess opening books. Unregistered filetypes, more than any other
kind of filetype, ought to be presented to the user for instructions on whether
to open or save to disk, where, what name, and what program (if any) should be
used to open the file.

Why should we need to repeatedly fight this battle to get the coding right?

Comment 5

13 years ago
I re-installed Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910
and found the following:

An exe file is automatically recognized by Mozilla and a "save as" box appears
to specify the location and filename. This is happening in connection with an
FTP server.

A zip file goes through the "save or open as" dialog, and then the "save as" box
is displayed when I choose to save the file. The zip file does not remain in the
system temp directory after I indicate the name and location for saving. Partial
files from cancelled downloads seem to be properly deleted.

An .iso, .bz2, .img or other file of a type not recognized by the system does
NOT go through any of the above dialogues, but instead is automatically saved to
the temp directory with a random filename (extension preserved) and then Mozilla
brings up the system dialog about what program to open it with. So this part of
the downloading bug is found in Mozilla 1.7. Maybe Mozilla 1.6 will have it right.

A file of an unrecognized type should go through the same dialog as a zipfile or
other recognized filetype.


Comment 6

13 years ago
The regression in download-file handling occurred in going from 1.7.3 to 1.8x. 

The following describes some clumsiness that was fixed in 1.7 before someone
unfixed it in version 1.8. 1.7.3's file download handling therefore seems better
than 1.8a5's.

Using files from the ibiblio server linked from http://www.freedos.org/, version
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 used the "save or
open as" dialog and the "filename and location" dialog to save a zip file, but
first saved it as a randomname zipfile in the Windows temp directory before
moving it to its destination.

Using the firefox-setup.exe file as a sample exe file, I found that the "save or
open as" dialog was skipped, but the "filename and location" box and other
details were the same as for the zipfile above.

An .img file was automatically opened as a text file in the browser window, so
that was very very far from correct.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

12 years ago
(In reply to comment #2)
> Then a bug with the XP build?

On Win 98 after selecting a download directory and an EXE file to open the
downloaded file, the same problem occurs.  That is download manager will not
allow change of the EXE file or the directory because it does not show anything
in Tools/Options/Download.  The only way around it was to delete the file 
C:\WINDOWS\Profiles\AliP\Application
Data\Mozilla\Firefox\Profiles\sdqxqpm2.default\mimeTypes.rdf
to get back the original popup download manager that allows new settings.

Comment 9

12 years ago
Works fine on Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b

-> WORKSFORME
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.