Whenever I download backups in gz format from cpanel Firefox reports the download size as 0. It is not zero, but I believe the server doesn't specify filesize initially, so Firefox can only know it after the download has completed. It used to be the case that after the download has finished bot download panel and library showed size correctly. Now both get it wrong right after it has finished downloading. Works in 25.0 20131025150754 Broken in 26.0a2 20131027004004

I'd also seen this a few days ago and remarked to Mike

There are two parts to this issue, that is showing that we don't know the final size while downloading, and getting the exact final file size of the download from disk instead of the amount of data transferred from the network. I think the first is the most important regression and can be addressed now, while I've filed bug 941063 for the second.

This simple patch fixes the major file size issue, though the displayed size may still be inaccurate for finished downloads. It is as self-contained as possible, so that it can be considered for fixing the regression in Beta. Steps to reproduce: - Copy the URL of a file for which the server does not specify the size, for example: https://tbpl.mozilla.org/php/getParsedLog.php?id=30834886&tree=Mozilla-Central&full=1 - Open the Downloads Panel and paste the URL with CTRL-V. Expected results: - While downloading, you should not see a total size of 0 bytes. - When completed, you should see a valid file size (though it may be less than the final size on disk when the file is compressed). Actual results before the patch is applied: - While downloading and on completion, you see a total size of 0 bytes. This patch touches the code that provide data about the current progress of the download. As a regression test, you can execute a download with a known final file size and check that progress is shown as expected.

Comment on attachment 8335383 [details] [diff] [review] The patch I'm told Neil is away, do you think you can review this patch potentially tracking Beta on short notice, Marco?

Tracking this regression but would like to know the risk/reward of taking this patch vs. considering a backout if the regression cause is known.

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #5) > Tracking this regression but would like to know the risk/reward of taking > this patch vs. considering a backout if the regression cause is known. This patch fixes code that uses the Downloads API that will be shipped in Firefox 26, so the choice here is between taking the patch on Aurora and Beta or leaving the regression in place. Any risk caused by this patch is limited to the progress indication of downloads. I think we should add a manual test case based on comment 3 to check for potential regressions.

Comment on attachment 8335383 [details] [diff] [review] The patch Review of attachment 8335383 [details] [diff] [review]: ----------------------------------------------------------------- I think it's a good stop-gap solution for branches, while waiting for bug 941063 ::: browser/components/downloads/src/DownloadsCommon.jsm @@ +893,5 @@ > + this._download.currentBytes; > + this.percentComplete = 100; > + } else if (this._download.hasProgress) { > + // If the final size and progress are known, use them. > + this.maxBytes = this._download.totalBytes; trailing spaces

Comment on attachment 8335383 [details] [diff] [review] The patch Note: I'm nominating this before it has landed on mozilla-central since I'll be away next week, the patch should be safe to land on Aurora and Beta after Nightly testing. [Approval Request Comment] Bug caused by (feature/regressing bug #): 825588 User impact if declined: Incorrect progress indication for downloads with no size Testing completed (on m-c, etc.): Tested locally, should be tested in Nightly when patch lands there Risk to taking this patch (and alternatives if risky): Any risk caused by this patch is limited to the progress indication of downloads. I think we should add a manual test case based on comment 3 to check for potential regressions. The patch is self-contained and can be easily backed out in case any issue occurs. String or IDL/UUID changes made by this patch: None

https://hg.mozilla.org/releases/mozilla-aurora/rev/26e50190587d https://hg.mozilla.org/releases/mozilla-beta/rev/c276b0be10cc

Verified this bug on FF 26.08 using the following environments: Ubuntu 12.04 x32 Windows 7 x64 The download size is different from 0 but the difference between the size displayed by the download panel and the size of the file on the disk is huge.( eg size on the disk 22 Mb download size displayed by the panel 660 kb). I will log a new bug for this issue.

Verified this bug on FF 27.0a2 build id:20131128004001 using the following environments: Ubuntu 12.04 x32 Windows 7 x64 The download size is different from 0 but the difference between the size displayed by the download panel and the size of the file on the disk is huge.( eg size on the disk 22 Mb download size displayed by the panel 660 kb). I will log a new bug for this issue.

Verified this bug on FF 28 build id:20131217004003 using the following environments: Ubuntu 12.04 x32 Windows xp x86 Os X 10.9 The download size is different from 0 but the difference between the size displayed by the download panel and the size of the file on the disk is huge.( eg size on the disk 22 Mb download size displayed by the panel 660 kb). I will log a new bug for this issue.