Closed Bug 62666 Opened 24 years ago Closed 23 years ago

download of new mozilla version fails miserably

Categories

(SeaMonkey :: UI Design, defect, P3)

Sun
Solaris

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 55690

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!
->mscott
Assignee: asa → mscott
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
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>
dupe of bug 55690

*** This bug has been marked as a duplicate of 55690 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.