910597 - [MP] Defect - Downloaded amount is always reported as "unknown size"

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: Downloads, defect, P2)

Description

[Francesco Lodolo [:flod]]

Firefox 2013-08-28 on Windows 8 Professional 64bit

First test
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/23.0.1/mac/en-US/Firefox%2023.0.1.dmg

Download is reported as unknown size/unknown size.

Second test
http://download.documentfoundation.org/libreoffice/stable/4.1.0/win/x86/LibreOffice_4.1.0_Win_x86.msi

Download is reported as unknown size/205 MB and never changes.

Firefox Metro should report how much has been downloaded.

Comment 1

[Marco Mucci [:MarcoM]]

Hi Juan, can you verify and provide steps to reproduce.

Comment 2

[Brian R. Bondy [:bbondy]]

> http://download.documentfoundation.org/libreoffice/stable/4.1.0/win/x86/LibreOffice_4.1.0_Win_x86.msi

This link leads to an object not found error.  It probably used to be valid but since became invalid.


> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/23.0.1/mac/en-US/Firefox%2023.0.1.dmg

This link correctly shows the file size and total size for me. 

Please re-open if you can still reproduce this, it may perhaps be related to a proxy in between you and your ftp server.


Also if you do re-open, please indicate if this only happens with FTP, or if it also happens with HTTP.

Comment 3

[Francesco Lodolo [:flod]]

Try with http://mirror.catn.com/pub/tdf/libreoffice/stable/4.1.1/win/x86/LibreOffice_4.1.1_Win_x86.msi

As for bug 910596: Fx 26.0a1 (2013-09-11), Win8 Pro in a VM from the Paris office, same result for both cases.

Comment 4

[Francesco Lodolo [:flod]]

Attachment: Download of Libreoffice

Comment 5

[Brian R. Bondy [:bbondy]]

To rule out that this is not a proxy issue, can you confirm that it does show the size correctly in Desktop Firefox on the same computer on the same network?

Comment 6

[Francesco Lodolo [:flod]]

Attachment: Same file downloaded from desktop version

Here's Firefox Desktop on the same VM, same network.

Not sure how a proxy could block the calculation of the downloaded part (while I could probably understand the size of the file to download.)

Comment 7

[Brian R. Bondy [:bbondy]]

> Not sure how a proxy could block the calculation of the downloaded part 
> (while I could probably understand the size of the file to download.)

Likewise I'm not sure why it would work for me and not you when running the same code on the same download link. But we are troubleshooting right? And while troubleshooting we try to learn more about the problem.  Maybe for example the proxy server was caching the downloaded file or blocking the connection on the data port.

Resetting back to Juan, I can't reproduce but Francesco definitely can.  Maybe you can find some extra steps that differentiate our two setups or something.

Comment 8

[Francesco Lodolo [:flod]]

I even tried with the en-US version to be sure it wasn't a problem with localized builds but I get the same results.

Comment 9

[juan becerra [:juanb]]

Tested on 2013-09-16 with a build from a few days ago and both links report what seems like a correct fraction of the download, say "156mb/205 mb." As with bug 910596, I don't know what the problem might be because the reported file size seems to be ok.

Comment 10

[juan becerra [:juanb]]

Francesco suggested I change the regional settings to change the "." separator for "," and after doing that and clicking on the download link I get an "Unknown size / Unknown size" in the download progress notification.

I changed the Windows settings in the control panel related to clock, language and region, and made them match his setup: https://www.dropbox.com/s/yjf49p157ep5h4e/Schermata%202013-09-16%20alle%2020.55.43.png

Comment 11

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1

What happens is that DownloadUtils.convertByteUnits returns an array with 2 elements. The first element is the formatted string with separator already replaced in string format.  So "." is replaced with "," already.

Treating this as a number directly won't work in javascript since you need to use a period as the decimal separator. It results in NaN even know it's a valid number.  Therefore I just check the validity of the input data. Desktop doesn't even check the value at all.

The alternative would be to replace back to decimal separator, which would be uglier.

Comment 12

[Matt Brubeck (:mbrubeck)]

Comment on attachment 805656 [details] [diff] [review]
Patch v1

Review of attachment 805656 [details] [diff] [review]:
-----------------------------------------------------------------

Nice find, guys!  I see that Firefox for Android has a similar bug; I'll file a follow-up for that.

::: browser/metro/base/content/Util.js
@@ +175,5 @@
>     * so they are joined for a single download size string.
>     */
>    getDownloadSize: function dv__getDownloadSize (aSize) {
>      let [size, units] = DownloadUtils.convertByteUnits(aSize);
> +    if (!isNaN(aSize) && aSize > 0)

Note that the isNaN check is redundant here, since (NaN > 0) is false.  So you can remove it if you want, or leave it for clarity.

::: browser/metro/components/HelperAppDialog.js
@@ +44,5 @@
>  
>    _getDownloadSize: function dv__getDownloadSize (aSize) {
>      let displaySize = DownloadUtils.convertByteUnits(aSize);
> +    // displaySize[0] is formatted size, displaySize[1] is units
> +    if (!isNaN(aSize) && aSize > 0)

Same here.

Comment 13

[Brian R. Bondy [:bbondy]]

Attachment: Patch v2.

Removed redundant isNaN check.  Thanks for the quick review.
flod thanks for tracking down the root cause.

Comment 14

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/integration/fx-team/rev/db58872e6aaf

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/db58872e6aaf

Comment 17

[juan becerra [:juanb]]

This is now working on the latest nightly built from http://hg.mozilla.org/mozilla-central/rev/ab4ccf3d6b60

I tested by toggling the region settings corresponding to decimal separators and in both cases, using "." vs ",", I got a total file size and current download size reported.

Comment 18

[Cornel Ionce [:noni] [Hubs QA]]

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Build ID: 20130929030202

Does not work for me in latest Nightly using Windows 8 x64.

STR:
1. Open nightly in Metro mode
2. Go to http://nightly.mozilla.org/
3. Click any download link and select "Save"

Results:
The download bar swipes down and the item is not downloaded. The progress bar and the download indicators are not working.
After several attempts, the file is shown in the downloads folder with a size of 0 kb.

Notes:
This works in desktop nightly.


Could someone please take a look into this issue?

Comment 19

[Cornel Ionce [:noni] [Hubs QA]]

Logged bug 922075 for the issue encountered in comment 18.

Comment 20

[Cornel Ionce [:noni] [Hubs QA]]

Mozilla/5.0 (Windows NT 6.2; rv:27.0) Gecko/20100101 Firefox/27.0
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Build ID: 20131020030202

Verified on latest nightly on Windows 8 32bit and 64bit.

I've tried using several donwloads (from 10mb up to 2gb) and the total file size was shown for each download. Marking this as verified.

Logged bug 928858 for an issue discovered while several downloads were in progress (pressing "Cancel" will stop all the downloads).