128348 - download progress dlg sometimes doesn't appear, resulting in stalled or failed download

Status: VERIFIED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[sairuh (rarely reading bugmail)]

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?

Comment 1

[Peter Trudelle]

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'?  

Comment 2

[Steve Dagley]

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/>

Comment 3

[sairuh (rarely reading bugmail)]

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.

Comment 4

[Peter Trudelle]

nsbeta1+ per Nav triage team, ->1.0

Comment 5

[Jaime Rodriguez, Jr.]

Changing to ADT2 per ADt triage.

Comment 6

[Peter Trudelle]

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.

Comment 7

[Peter Trudelle]

nsbeta1- per Nav triage team, ->1.1

Comment 8

[Stefan Seifert]

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

Comment 9

[Chris Petersen]

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.

Comment 10

[Chris Petersen]

Verified