User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040927 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040927 The download dialog quit working in Mozilla 1.7.3 for me today, and I installed 1.8a4 for Windows. The problem is now worse. The download dialog box should indicate 1) open with default application, 2) open with specified application, 3) save to disk. The "save to disk" choice should open a "save as" dialog that lets the user specify the filename and location to save to. This quit working, and files started getting saved today into Windows\temp without asking. The files I've been downloading lately are chess-related exe, bin and zip files. I want them saved, not opened. Mozilla has been very good until now about not automatically opening files of risky MIME types, one of the great security problems of MSIE. Mozilla should not start being stupid now. I removed 1.7.3 and installed 1.8a4, and the problem got worse. Now, when I try to download a file that I downloaded yesterday (gromit382.zip for Winboard on the URL indicated above), Mozilla gives the message that a randomly generated filename.zip could not be saved because the source could not be read. First of all, no downloading took place, no attempt to download. Mozilla only produced an error message. Second, Mozilla's downloading was already supposed to be fixed. This is a regression. Mozilla is supposed to start a download in the system temp directory while the "save as" dialog box is open, and then move the partial download to the permanent location with the user-specified filename as soon as the dialog box info is entered. The error message is: C:\WINDOWS\TEMP\rzx3vqya.zip could not be saved because the source file could not be read. Try again later, or contact the server administrator. Where in Mozilla source code is this error message, and what calls it? Why is the actual downloading code skipped? Why are the dialog boxes skipped? Why are files that aren't MIME types designated to be immediately opened not handled by the dialog boxes? I'm going to see if the problem exists in earlier versions of Mozilla now. These problems developed just in the past day or two, on version 1.7.3 for Windows. I seem to be downloading from http://www.delorie.com/djgpp/zip-picker.cgi now, but no dialog box opened. My Windows\temp directory has 5 files with random names, 4 exe files and one zip, of size zero. I assume this means the downloads are incomplete. But I have no download window to pause or cancel downloads, even after clicking on Tools\Download Manager. Software installations including upgrades of Mozilla should be done with the user's permission, with a notification of an available change and request to install, each and every time. No more automatic installs, please. I'm going to remove 1.8a4 and go back to 1.7.3. Reproducible: Always Steps to Reproduce: 1. Go to a URL for downloading a file (exe, zip) 2. Click on the link to download 3. Observe absence of normal dialog boxes Actual Results: Sometimes an immediate error message, sometimes a download with a random filename that's unusable. Expected Results: For any filetype not explicitly designated as a file to open with a default application (graphics, sound, macromedia flash, Adobe pdf, etc), there should be a dialog box asking what to do with the file (open with default, open with specified, save to disk). Save to disk should evoke a "save as" dialog box. It may save a few seconds to start the save to a temp directory, but the partial file should be moved to the specified location and name as soon as it's entered. This is already supposed to be fixed in Mozilla versions prior to 1.8.
After re-installing 1.7.3 for Windows, I found that exe and zip files are handled by the download dialog boxes, but bin files (not a filetype registered on the system) are automatically downloaded to Windows\temp, although using the original filenames. Any file that's not designated to be automatically opened by the browser (jpg, wav, mid, swf, gif, png, etc) ought to be sent through the dialog boxes. I don't see any preference either in the preference menu item or the about:config for how filetypes undefined to mozilla are handled.
Try deleting compreg.dat (it's in your components folder in your program folder). If this fixes it, this is dupe of Bug 227439
The compreg.dat file that I've been using (the one with 1.7.3) has been working fine until yesterday or today. After removing 1.7.3 (removing all program files) and reinstalling, compreg.dat should be restored to its condition as of 9-15-2004 which was OK. I don't think that's the cause of my downloading problem. If it's removed, will it be regenerated?
(In reply to comment #3) > If it's removed, will it be regenerated? yes, it is just a cache of component info for faster startup times
Has anyone else found anything re: this bug report? Is it a dupe? When you try to download a file that's not a filetype known to Mozilla, does it automatically put the file into the temp directory and try to open it when the download's complete? I've had this experience downloading bin files from ftp sites.
Have any of these problems with 1.8a4 for Win9x been verified? Some of them are regressions to previous problems that were fixed in 1.7.x
See my comments in #199394.
Using a very recent nightly build (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050322, I did some experimenting to determine current downloading behavior, and found some inconsistencies. Downloading Thunderbird installer exe from Mozilla: No save/open dialog as expected downloading pcbooster-ns.exe from Netscape got save/open dialog box (not expected), got saving location box as expected. completed ok downloading an exe from funduc.com http://www.funduc.com/decext.htm got only the saving location box as expected downloading Netscape 4.8 for Windows exe file from ftp://ftp.netscape.com/pub/communicator/english/4.8/windows/windows95_or_nt/complete_install/cc32d48.exe Got neither dialog box on the first try, not expected. Transferring data from ftp.netscape.com showed on the status line. It quit at about 400K with the message, "can't save file because can't read source file" or something like that. On the second try, I got a save-location dialog box, expected but not consistent with the first try. The target folder has the file cc32d48.exe.part and the size is 73,888 bytes. This must be the file moved from Windows\temp that the rest of the download is being concatenated to. The download completed successfully. In trying to download a zipfile from funduc.com http://www.funduc.com/decext.htm I got both dialog boxes as expected. I tried downloading it again and checking the "Always take this action with this filetype" box in the open/save dialog, and cancelled instead of overwriting. Later in the same session tried downloading the same zip and got the open/save dialog again, completed the download and tried it again. Found that this time the "Always take..." setting was saved, so there was no save/open dialog. Later found that the download only needs to start to get the setting saved. Trying to download a bin file, Mozilla 1.0.1 stub installer for Mac Os9, from http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.0.1/ File cmxj2pyf.bin is opened in Windows\temp silently with no dialog boxes for save/open or saving location. There's the problem that the file may be larger than the available space on the disk. There's no assurance that the downloading code checks for adequate space first. After the download, the operating system (Win98) tries to open the bin file, instead of just letting Mozilla or the user save it. If the file isn't opened, it will not be saved. I set Debug as the program for opening bin files, a kludgy way to get the file saved. That's the only way I have to save a .bin download, such as the opening book files for the Crafty chess engine. On first try, there appeared to be a filesize error, 67K instead of 152K or so as indicated in the Mozilla FTP folder. I tried downloading 2-3 more bin files from the Mozilla FTP folders, successfully but with no dialog, and with the requirement to open them with Debug (by Windows file association settings) in order to save them. They must be moved from Windows\temp to the destination folder manually. Testing a gz file in the same folder, I got save/open and saving-location dialog boxes as expected, showing recognition of the filetype and application that would open it. The behavior described here shows a bit of inconsistency, and also shows that if a filetype is not known to Mozilla/Firefox, it's even more appropriate to present the user with the open/save dialog and the saving-location dialogs.
Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050809 SeaMonkey/1.0a, I tried downloading the Linux x86 Seamonkey nightly right after installing and starting Windows Seamonkey. An ftp transaction started without ANY dialog, and because there was no dialog, I had no way to stop it except to kill Seamonkey and/or the online connection. I found that the file was evidently being stored in C:\Windows\temp with a random name. On restarting Seamonkey, I tried setting the download preferences several times. As you know, the options are Open Download Manager, Open Progress Box, Open nothing. The original download started as if the "Open nothing" preference was set. With nothing opened, there was nothing to click to stop the download. Anyway, I set download preferences and clicked OK to make sure the prefs were freshly saved instead of having whatever was set at installation. Then the downloading seemed to work right. Check the settings sent in the installation file. If compreg.dat or some other registry setting is at fault, it should be set correctly in the running program before downloading, etc is attempted.
SeaMonkey v1.0.x is not supported anymore. Can you reproduce with SeaMonkey v1.1.9 ?
(9+ months later) No reply from reporter R.Incomplete Please reopen if you can reproduce with SeaMonkey 2.0a3pre running on a minimum of Win2k. SeaMonkey 1.0.x is long gone and Win98 is EOLed. SeaMonkey trunk doesn't work on win98 either.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.