265278 - file download failure, dialog missing

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Download & File Handling, defect)

Description

[John T]

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.

Comment 1

[John T]

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.

Comment 2

[Frank Wein [:mcsmurf]]

Try deleting compreg.dat (it's in your components folder in your program
folder). If this fixes it, this is dupe of Bug 227439

Comment 3

[John T]

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?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

Comment 5

[John T]

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.

Comment 6

[John T]

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 

Comment 7

[John T]

See my comments in #199394.

Comment 8

[John T]

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.

Comment 9

[John T]

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.

Comment 10

[Serge Gautherie (:sgautherie)]

SeaMonkey v1.0.x is not supported anymore.

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 11

[lenochod]

(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.