Closed
Bug 67481
Opened 24 years ago
Closed 23 years ago
downloading files > ~2MB dialog does not update
Categories
(SeaMonkey :: UI Design, defect, P2)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: le_jawa, Assigned: mscott)
References
()
Details
(Keywords: regression, Whiteboard: critical for 0.8, [nsbeta1+])
Attachments
(1 file)
759 bytes,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010201 BuildID: 2001020104 When I try to download files about 2MB or more, the 'Saving File' dialog appears to quit responding, except for the 'Cancel' button. Also, 'Elapsed Time' shows an invalid value. Reproducible: Always Steps to Reproduce: 1.) Click on a link to download a file known to be at least 2MB in size. (FOr example: http://ftp.mozilla.org/pub/mozilla/nightly/2001-01-31-09-Mtrunk/mozilla-win32-installer.exe) Being a known/unknown filetype does not seem to matter, neither does filename length or protocol (FTP, HTTP). 2.) When the 'Downloading' dialog appears, select 'Save to disk' (if it is an option) and click 'OK'. 3.) In the next dialog, enter a filename if you wish and click 'OK'. Actual Results: The Saving File dialog will appear. The progress meter will not move, the "Elapsed Time" will display a seemingly random number, and the "Launch File" and "Reveal Location" buttons will remain greyed out, even when the file is finished downloading. Although greyed out, the buttons still work. "Time Left" will stay at 00:00. Expected Results: Progress meter should show progress, the buttons should not be greyed out, and the timers should track time elapsed and remaining.
Comment 1•24 years ago
|
||
Confirmed in Mac 2001020208 MTrunk. All/All.
Status: UNCONFIRMED → NEW
Component: Networking: FTP → XP Apps
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Comment 2•24 years ago
|
||
Appears to be a dup of Bug 67411 http://bugzilla.mozilla.org/show_bug.cgi?id=67411
Comment 3•24 years ago
|
||
Bug 67411 reports that there is no actual download, which is not the case here. Reassiginig to mscott who checked in the fix for bug 67047.
Assignee: dougt → mscott
This _is_ a duplicate of bug 67411. I guess the reporter didn't notice the download, but in fact it does download the file, but silently.
Of the builds I tested on, the download only occurs with 20010201, I couldn't get 20010202 to download the file at all (tested twice). This under Linux, that is.
Comment 7•24 years ago
|
||
Updating summary. was Trouble downloading files > ~2MB; dialog appears to freeze Adding mozilla0.8 keyword. This is pretty ugly. The download functionality is working but the progress dialog is broken. This leads people to hit the Cancel button with removes the downloaded file. mscott, can you please take a look at this soon. We freeze for 0.8 tomorrow night and hope to ship by 2/12. We shouldn't ship with this breakage.
Severity: normal → critical
Keywords: mozilla0.8,
regression
Summary: Trouble downloading files > ~2MB; dialog appears to freeze → downloading files > ~2MB dialog does not update
Whiteboard: critical for 0.8
Assignee | ||
Comment 8•24 years ago
|
||
I am unable to reproduce this behavior using a Wn32 release build from 02/06/01 anyone else?
Still here on 2001020609/Linux. I don't see the stuff about the file being deleted when I hit cancel, but I never did see that in the first place. The behavior I'm seeing on the above build: 1.) Download progress dialog shows no activity at all. 2.) File doesn't show up with an 'ls' (i.e. appears not to be written to file system) until download has _fully_ completed. This may explain the lack of activity on the progress bar described in #1. 3.) Download is very slow (arguably not a part of this bug). I suppose it's possible that the download dialog will update all at once some time after the file is finally written, but I waited for a while and it never did.
Assignee | ||
Comment 10•24 years ago
|
||
then maybe it's the problem with ftp. Ftp is broken in the daily builds until the necko branch lands. It causes the CPU to get pegged at 100% and can starve out the UI thread. Are you testing this on an ftp url?
Comment 11•24 years ago
|
||
I tried one more time and noticed that there is disk activity during the download even though the file doesn't show up... Could be it's being saved to a temp file, then relinked to the specified destination at the last minute and the download dialog doesn't know this... this is, of course, just a wild guess since I'm not familiar with the code.
Comment 12•24 years ago
|
||
No, it's not ftp since I'm downloading from an http:// url http://ftp.mozilla.org/pub/mozilla/nightly/...
Comment 13•24 years ago
|
||
mscott, if you'd like to come to my cube I can show you what's happening here. I don't think that it's related to the ftp or networking problems. The download happens, the dialog just doen't know that. So the download finishes and the dialog sits there looking like the download never started.
Reporter | ||
Comment 14•24 years ago
|
||
My apologies to Asa, mscott and Dave -- I evidently didn't word part of this clearly enough. I already tested to see if protocol (FTP, HTTP), filename length or filetype (extension) made a difference. None of them do. The only thing that made a difference for me was file length. Files ~1.5MB and smaller to worked fine. Files ~2MB and larger seemed to cause the problem.
Comment 15•24 years ago
|
||
Yes, size matters in Mac builds too.
Comment 16•24 years ago
|
||
Confirming, size does matter, on Linux (same build). With the large tar.gz files of ftp.mozilla.org, I get the two new buttons added recently (open file and reveal location) and I also get the problem. With small files, however, I don't get the above mentioned buttons (just a Cancel button) and the progress bar moves. FYI, I tested small files by right clicking and saving a 14K jpg.
Comment 17•24 years ago
|
||
Actually size does NOT matter. I was able to reproduce this with a few Kbytes long .zip file. Thanks to Dave to discover that there are actually two different dialogs: 1. downloadProgress.xul + downloadProgress.js 2. helperAppDldProgress.xul + helperAppDldProgress.js The former works the latter does not. The 2nd type dialog is invoked from: http://lxr.mozilla.org/seamonkey/source/xpfe/components/ucth/src/nsUnknownContentTypeHandler.cpp#186 This happens when you click on a link and the content type dialog comes up, you choose 'Save file'. To test, go to http://ftp.mozilla.org/pub/mozilla/nightly/latest/ and click on one of the .zip files. The 1st type dialog is comes up when you save a file manually, by save page, save image, save link as... I think this is: http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/src/nsStreamXferOp.cpp#79 To test, go to http://ftp.mozilla.org/pub/mozilla/nightly/latest/ and eighter shift+click on one of the .zip files or choose save link as from the context menu. So there's two bugs: - There are two different dialogs for download progress. - The 2nd dialog helperAppDldProgress doesn't work.
Comment 18•24 years ago
|
||
Sorry for the spam, just adding to CC list.
Comment 19•24 years ago
|
||
Peter, you are mistaken about this bug. If you go to the Mozilla nightly directory and click one of tar.gz file which is small(for ex. less than 1MB), this Saving File dialog disappears after DL is complete. However, if you click a large tar.gz file, the same Saving File stays forever. The lack of progress and other oddities are not what this bug is about. This bug neither involves the Save Link As etc. In Mac build, hitting cancel after DL is complete (judging from the size of the DLed file) does not delete the DLed file, further supporting that Mozilla finishes actual DL, but fail to take care of the dialog window. The lack of progress bar may be related to this symptom, but could be independent.
Comment 20•24 years ago
|
||
I am able to isolate 4 different situation, 1 of which shows the symptoms from this bug: 1.) Downloading http://ftp.mozilla.org/pub/mozilla/nightly/required-by-law/glib-1.1.6.tar.gz (249k) A.) When LEFT clicking on file to d/l, I get the dialog with the open file and reveal location buttons and the download IS successful. B.) When RIGHT clicking and choosing "save link as...", I get the dialog with ONLY a cancel button and the download IS successful. 2.) Downloading http://ftp.mozilla.org/pub/mozilla/nightly/2001-02-06-09-Mtrunk/mozilla-gcc295-i686-pc-linux-gnu.tar.gz (10M): A.) When LEFT clicking on the file, I get the dialog with the extra buttons (as with the above case "A") along with the symptoms of this bug (dialog stays after download is complete). B.) When RIGHT clicking and choosing "save file as..", I get the dialog with only a cancel button which DOES update as the download progresses. Strangely, this case made the browser crash. I submitted talkback incident TB25955648Y for it. In conclusion, it appears that, of the two dialogs Peter found, one of them fails to update ONLY when downloading a large file.
Comment 21•24 years ago
|
||
I tested case 2-B again (download 10M file with right click and "save link as..." Dialog with only a cancel button). This time there was no browser crash and the file was successfully downloaded with updating dialog (like case 1-B). So, new steps to reproduce this bug: 1.) go to http://ftp.mozilla.org/pub/mozilla/nightly 2.) choose a build directory. 3.) Download a build by LEFT CLICKING on the link to the file (make sure the file is greater than 2M). 4.) You will see a download dialog which will NOT update and wil stay after the file is successfully downloaded.
Comment 22•24 years ago
|
||
Re: Dave tests. Testing 2001-02-06-04 on Win98SE. Btw, this is behind a proxy server. I tested the 1.A case. 1st try actual download: I get the dialog with the Launch file / Reveal Location buttons. I get NO update on downloading progress. When the download finished the dialog stays on the screen. Pressing cancel after successful download deletes the file. 2nd try file is cached by the proxy server: (The download actually finishes before I get trough the dialogs.) I get the dialog with the Launch file / Reveal Location buttons. I get the dialog with 100% initially. The dialog disappears after 2 seconds. The downloaded file is kept. I think that people don't experience this problem with short files is that they have a (too :) fast internet connection, and the download actually finishes, before they get trough the two dialogs. The new download dialog seems to get updated only once, and no more. So if the download already done by the first update, the dialog behaves correctly.
Comment 23•24 years ago
|
||
Very good analysis, Peter. Since DL to temp folder continues before you OK to the Save dialog, if you wait long enough so that the DL of a large file is complete before you hit OK to start DL, the Saving File dialog disappears immediately. So, this is dialog updating problem resulting in lack progress bar and time.
Comment 24•24 years ago
|
||
*** Bug 67984 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
*** Bug 68037 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
Bill, ideas?
Comment 27•24 years ago
|
||
This was caused by valeski's 1/31 fix to nsDocLoader.cpp to store weak referencess to listeners. Apparently aListener doesn't support weak refs...
Assignee: mscott → valeski
Updated•24 years ago
|
Comment 28•24 years ago
|
||
hmmm, I grepped for "public nsIWebProgressListener" and made everyone support weak ref. Did I miss one?
Assignee | ||
Comment 29•24 years ago
|
||
great catch Blake. Yeah you missed ones implemented in JS =) which includes the progress download dialog. I have a patch i'm about to post now. Can someone who sees this behavior try this out?
Assignee: valeski → mscott
Assignee | ||
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
coolness, looks good (and fixes the problem for me). r=blake if you combine the two interface checks.
Comment 32•24 years ago
|
||
a=asa for checkin to 0.8. just need sr=
Comment 33•24 years ago
|
||
cool! sr=alecf
Comment 34•24 years ago
|
||
r/sr=sspitzer
Assignee | ||
Comment 35•24 years ago
|
||
thanks guys. I checked in the fix (using a single if clause)
Status: NEW → RESOLVED
Closed: 24 years ago
Keywords: nsbeta1
Resolution: --- → FIXED
Whiteboard: critical for 0.8 → critical for 0.8, [nsbeta1+]
Target Milestone: --- → mozilla0.8
Comment 36•24 years ago
|
||
This appears to be fixed on 2001020909/Linux. However, now the "Launch File" and "Reveal Location" buttons don't do anything, even with a new profile. Is there a bug for this?
Comment 37•24 years ago
|
||
Dave - Yes, look for it in Bugzilla. Those two buttons are new features, implementation for systems other than MacOS/Windows is helpwanted. If you can think of a desktop-agnostic solution for Linux please track down the helpwanted bug and volunteer it. It doesn't have anything to do with this bug anyway.
Comment 38•24 years ago
|
||
dave and ruth --the issue with Reveal Location on linux has been filed in bug 67001.
Updated•24 years ago
|
Keywords: mozilla0.8
Comment 39•23 years ago
|
||
This problem is back. Using the 3/19 Mac build from sweetlou, try to download another build from sweetlou. The file will actually be downloaded and even decompressed when finished (which was my choice in the dialog), but there will be no progress in the dialog.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•23 years ago
|
Priority: -- → P2
Target Milestone: mozilla0.8 → mozilla0.9
Assignee | ||
Comment 40•23 years ago
|
||
conrad are you still seeing this on recent builds? I'm not able to reproduce what you were seeing when you re-opened this. but i haven't tried on my Mac yet. It may be mac specific. I'll try that next.
Comment 41•23 years ago
|
||
No, just tried it again and all was well.
Assignee | ||
Comment 42•23 years ago
|
||
coolness! reclosing...
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 43•23 years ago
|
||
VERIFIED: Mozilla 0.9 allplats. This works now. I see numbers and a thermometer.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•