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.
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.
Then a bug with the XP build?
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.
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?
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.
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/
(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.
Works fine on Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b -> WORKSFORME