Closed
Bug 62666
Opened 24 years ago
Closed 23 years ago
download of new mozilla version fails miserably
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
People
(Reporter: gtr, Assigned: mscott)
References
()
Details
From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u) BuildID: 2000112921 Reproducible: Always Steps to Reproduce: 1. Go to nightly builds directory for the "etc" category. 2. Click on mozilla-sparc-sun-solaris2.6.tar.gz 3. Select save-to-disk from dialogue; get save-as dialogue 4. Use horrible clunky navigation to point it to a directory on a disc with enough free space to save it. 4. Press save. Actual Results: Save-progress dialogue comes up, then goes away within ~2s, having not shown any progress. mozilla says: "Document $s2.6.tar.gz loaded successfully we don't handle eBorderStyle_close yet... please fix me Move window by 427,178.4 screen x 139screen y 101 we don't handle eBorderStyle_close yet... please fix me JavaScript error: chrome://global/content/filepicker.js line 142: uncaught exception: [Exception... "Component does not have requested interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "<unknown>"]" File mozilla-sparc-sun-solaris2.6.tar.gz then exists on disc, but is shorter than expected (actual length has varied from ~9MB to ~11MB). gunzip says "unexpected end of file" when decompressing it. Expected Results: Dowload goes gradually, takes maybe 15 minutes for 11.8MB; save-progress dialogue shows steady progress. Gunzip decompresses the file without barfing. No way is it going to shift 11.8MB in less than two seconds. Our link is fast but not that fast!
Comment 1•24 years ago
|
||
->mscott
Assignee: asa → mscott
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
Assignee | ||
Comment 2•24 years ago
|
||
we start downloading the file into a temporary directory. Do you have enough disk space in that directory? On linux it should be the directory defined by your TMPDIR environment variable. Do you have enough disk space there?
TMPDIR is not set in my environment. If the download starts in either /tmp or /var/tmp, then there is plenty of space. If it goes for my home directory, then there is space on the disc, but relatively little disc quota; it is possible that it would have just gone over-quota on the day when I reported this. But why should it not use the directory that I selected in the dialogue?
Per mscott, we start downloading *BEFORE* you specify a location, which means we can't always pick the same spot as you do, because you might come when the download is 100% complete and pick a location. Please set a TMPDIR that is acceptable <p class=hypothesis> As for the reason why... I think some people accidentally start save sessions (worse, some servers randomly send a save session w/o the user expecting it) w/o realizing they need to pick a location, and many servers will timeout and such, so it's important for the browser to get the data.</p>
Comment 5•23 years ago
|
||
dupe of bug 55690 *** This bug has been marked as a duplicate of 55690 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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
•