Closed Bug 41418 Opened 25 years ago Closed 25 years ago

Download of Linux Nightly using NT does not work.

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 33808

People

(Reporter: robert.thorneycroft, Assigned: gagan)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m16) Gecko/20000603 BuildID: 2000060308 When selecting to download the Linux nightly build the file that downloads is actually 24,670K on my PC rather than the 7,267K that the browser implies it should be. Also the download speed displays as being about 4 times the actual bandwidth I have available (I wish), and the percentage download goes way over 100%. Reproducible: Always Steps to Reproduce: 1.Go to www.mozilla.org 2.Download the latest nightly build of the linux browser using the windows browser Actual Results: The file downloaded is over 3 times larger than it should be. Expected Results: File should be downloaded correctly.
Is this being caused by the auto-ungziping? Theres a seperate bug open for removing that.
Changing component from "other" to "Browser-General", setting default owner.
Assignee: chofmann → asa
Component: other → Browser-General
QA Contact: leger → jelwell
sounds like the auto-ungzipping. I believe this bug is invalid. Mozilla uncompresses .gz files when it downloads them. I can't find a bug on removing that.
Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
reporter - does the download work? I've seen this happen before (especailly the 4 times faster download rate). going to check into this.
->progress window (?) I don't really think that's right, though. who handles downloading? networking?
Assignee: asa → evaughan
Component: Browser-General → Progress Window
QA Contact: doronr → sairuh
-->networking
Assignee: evaughan → gagan
Component: Progress Window → Networking
QA Contact: sairuh → tever
This is a dup of a bug I reassigned to Networking yesterday, bug #33808. For some reason (perhaps auto-decompressing that's going on) we get more bytes than the content-length indicates. Maybe if decompressing, the channel should extrapolate a new content-length (or at least provide a modified "max" on the progress notifications). The dialog would be a bit flaky (with progress fluctuating and maybe going backward slightly).
duplicate of bug 33808 *** This bug has been marked as a duplicate of 33808 ***
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
verified Dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.