this is a tricky bug, because it doesn't happen all the time --but i have seen this crop up in recent builds and thought it should at least be tracked somehow. i've encountered this on all platforms, but most often on mac 10.1.3 and linux rh7.2. and, i've seen this with both ftp:// and http:// downloads. recipe: in this case, using 2002.02.27.08 comm bits on mac 10.1.3. 1. go to http://mozilla.org/ 2. in the "nightly builds" section, click on the "i386 Linux" link. 3. in the helper app dlg, "open with Stuffit" is selected in my case --change this, however, to "save to disk". 4. in the resulting file picker, i chose to save the file to the desktop. 5. click "save" in file picker. results: file picker and helper app dlgs are dismissed...but no download progress dialog appears, and no file appears on the desktop --whether with the salted name or final/actual filename. 6. wait about 5 or so minutes --it's not that big of a file... still progress dlg, or file on the desktop. surf around for a couple minutes more... click on the desktop to go to the Finder --still no file. in one case, the file finally appeared on the desktop. 7. if no file appears at step 6, quit the app. at this point, no file is ever downloaded. :( observation: i have noticed at step 6 on linux (at least) that the /tmp directory does contain the salted file. however, if i end up quitting the app (going to step 7), the download doesn't finish. iirc, i think the salted file remained --there was no completed/final file downloaded-- but i'm not sure. having trouble repro'ing this on linux today, alas. :( has anyone else experienced this, or have ideas as to why i'm encountering this bad state?

Yet another defect related to the 'save in temp' behavior. How often does this happen? Have you only seen it when changing the handling of the file, as in from 'open with Stuffit' to 'save to disk'?

Just to comment on the Mac bahavior - the temp dir for DL == the user specified download folder so _something_ should appear in the folder. Not that it's the cause of this problem but sometimes the Finder under OS X is vvvvveeeerrrryyyy slow to notice a change in folder contents (I often see no result from expanding a file w/StuffIt Expander until I force an update of the folder contents). BTW, if one is in need of a tool to monitor network traffic on Mac OS X, say to see if any data is actually being xferred during a download, try Sniffles which is available at <http://members.aol.com/ShaqDieselInc/>

i'm still seeing this on mac 10.1.3 with 2002.03.11.08 comm bits, using the steps i originally reported. :-/ peter, thanks for asking --i think i may have narrowed this down to *some* .gz files which use the stuffit file association. for example, using the download links from http://mozilla.org/ : a1. this bug will occur if you try the i386 Linux, Linux PPC, Solaris, FreeBSD, or HPUX links. a2. similar to (a1), except that i selected "Save Link As" from the context menu --not going through helper app dlg. still did not get the progress dialog. b. oddly, this bug will not occur if you try the Irix or BSD/OS links --even though the helper app dlg displays the same mimetype (application/x-tar, "Unix Tape ARchive"). c. did not get see this bug with the other download links on that page --which had different mimetypes.

nsbeta1+ per Nav triage team, ->1.0

Changing to ADT2 per ADt triage.

removing plus for re-triage, low impact due to only affecting a very small number of users, and then jmostly when handling foreign files that have bad mappings.

nsbeta1- per Nav triage team, ->1.1

This is very annoying. I see this quite frequently on two different computers with CVS builds in Linux. It happens for different files, e.g. .zip files that failed to download just now. Please reconsider the importance of this bug, it makes working pretty difficult for me. But it's interesting that I just recently noticed this bug the first time but it was opened in February

Using the both the trunk (2002-10-17-08) and branch (2002-10-14-05) OS X builds, I can't reproduce the issue which is described. Tested under 10.2.1. Marking WFM.

Verified