545707 - Software update reports transfer speed in bytes per second

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Marius Hudea]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.3a1pre) Gecko/20100205 Minefield/3.7a1pre (.NET CLR 3.5.30729)

When upgrading from Minefield 3.7a1pre to a2 the software update reported speeds in bytes/s when they were actually in KB/s

Reproducible: Always

Comment 1

[Robert Strong (they/them - no direct email)]

The dialog uses DownloadUtils.jsm and will display "bytes", "kilobyte", "megabyte", "gigabyte" for each chunk that is downloaded and it is very possible for it to display bytes for individual chunks due to any number of factors involved.
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/DownloadUtils.jsm#93

Does it actually only display bytes for each update?

Comment 2

[Marius Hudea]

It downloaded 18-20 MB or whatever size it was showing all the time 63 bytes/s 112 bytes/s 180 bytes/s while it was actually KB/s. Download was completed in about a minute so it was definitely not bytes/s but actually KB/s.

Comment 3

[Robert Strong (they/them - no direct email)]

I tried to reproduce with a 3.7a1pre nightly and it reported correctly. Please check if it still does it with the next nightly and report back your findings in this bug.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

I saw something similar with Mozilla/5.0 (Macintosh; U; Intel MacOS X 10.4; ne-US; rv1.9.2.2pre) Gecko/20100211 Namoroka/3.6.2pre, updating using a complete update to the the 0213 build after manually checking for updates. I was consistently seeing a few hundred "bytes/second", when the Activity monitor indicated 10-300 KB/s was being downloaded. I accidentally updated the backup copy I made, and couldn't reproduce with a fresh download of the 0211 build.

Also, if I hid the update dialog and reopened it, then it seemed to count all the previous download as happening right then, so the indicated transfer rate was very high and slowly came down as time passed.

Comment 5

[Marius Hudea]

It happened again right now, when I upgraded to 3.6, from that small popup saying i should upgrade. Clicked on Upgrade now or whatever it was and speeds were reported in bytes and kilobytes while the download was progressing... see pictures in the zip (used print screen and pasted in several irfanview windows because this was through remote desktop

Comment 6

[Marius Hudea]

Attachment: pics showing speeds in bytes and kbytes - actual transfer was done ~ 1 minute

Comment 7

[Marius Hudea]

Oh and sorry for posting again but it was from the default Firefox that was before 3.6, not from any nightly builds.

Comment 8

[Robert Strong (they/them - no direct email)]

Just so I know... was the update ever downloaded in the background in that you opened the update window while the download was already in progress?

Comment 9

[Robert Strong (they/them - no direct email)]

This is really strange... we get the transfer rate from nsIncremetalDownload and we hand this data off to DownloadUtils.jsm for formatting. Besides that app update doesn't do all that much with the values. Is there anything unusual about your system?

Comment 10

[Robert Strong (they/them - no direct email)]

I'd like you to try something

Open the following directory from the search box in the start menu on Vista.
%LOCALAPPDATA%\Mozilla\Firefox

In that directory there should be a Mozilla Firefox directory. Open it.

In that directory there should be two files - active-update.xml and
updates.xml. Open the updates.xml in a text editor.

Find the first value of URL= where URL= has a leading space (e.g. " URL=").
Download the mar file in the value for URL.

In the download manager verify that it is reporting the correct transfer speeds.

Comment 11

[Marius Hudea]

It's a dedicated server in the Leaseweb datacenter in NL, running Windows 2003 Web Edition. Otherwise, nothing particularly special about it.. AMD single core, 2.2 Ghz, 2 GB of memory, two 250 GB hard drives. It's on 100mbps port so no question of speed, download ended in probably less than a minute (just enough to do those print screens).

> was the update ever downloaded in the background in that you
opened the update window while the download was already in progress?

No, I don't think so. I usually select No, Download Later, or Download now (ok maybe they're not called like that but you get the idea). I use often around 15 tabs and I keep the browser open for weeks so I usually delay updates until I can afford to restart the browser completely.

In case anyone thinks extensions, I have just Flashblock and Clean up my places.

Comment 12

[Marius Hudea]

mirrors.yocum.org/mozilla/firefox/releases/3.6/update/win32/en-US/firefox-3.6.complete.mar

10.6 MB, downloaded with around 460KB/s average, as shown in the Download Manager

Comment 13

[Robert Strong (they/them - no direct email)]

Thanks Marius! I'll comb through the code to see if there is anything that looks like it may cause this to happen under some circumstances. It would be helpful to know if a non Windows 2003 Web Edition system (preferably a desktop system) exhibited the same behavior but if it isn't possible I completely understand.

Comment 14

[Marius Hudea]

Just a thought... could it be that when it computes transfer rate, it uses somewhere an uninitialized time or the time when the window has popped up instead of the time when the transfer has started? 

The window was probably on the screen for around 20 minutes - an hour before I chose to start the transfer as I keep the Remote Desktop minimized - if the time when the upgrade window was shown was used, the code may assume 1 MB or so was transferred in 30 minutes (showing 580 bytes/s)

Comment 15

[Robert Strong (they/them - no direct email)]

Possibly but I would think many others would have seen this same issue by now if it were due to anything being uninitialized. I'll try leaving the ui up for an hour and then upgrade to see if I can reproduce.

Comment 16

[Robert Strong (they/them - no direct email)]

I was able to reproduce using 3.5.8 and updating to 3.6... I'll look into this further hopefully within the next week or two

Comment 18

[Robert Strong (they/them - no direct email)]

Turns out the start date / time was initialized on window creation. I've got a patch in progress to fix this and a couple of other issues with the progress.

Comment 19

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

I'm going with the simple fix for this bug and will file a separate bug for the case where the user opens the UI while there is an update download in progress, etc.

Comment 20

[Robert Strong (they/them - no direct email)]

Filed bug 552724 for the additional issue found

Comment 21

[Justin Dolske [:Dolske]]

Comment on attachment 432862 [details] [diff] [review]
patch rev1

>+    // Dispatch ValueChange for a11y
>+    var event = document.createEvent("Events");
>+    event.initEvent("ValueChange", true, true);
>+    this._downloadProgress.dispatchEvent(event);
>+

Did you mean to make this change in this patch? Seems unrelated.

Comment 22

[Robert Strong (they/them - no direct email)]

(In reply to comment #21)
> (From update of attachment 432862 [details] [diff] [review])
> >+    // Dispatch ValueChange for a11y
> >+    var event = document.createEvent("Events");
> >+    event.initEvent("ValueChange", true, true);
> >+    this._downloadProgress.dispatchEvent(event);
> >+
> 
> Did you mean to make this change in this patch? Seems unrelated.
I didn't mean to... I'll remove and attach the updated patch before checkin

Comment 23

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/fd765b970adc