bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Transferred data column isn't updated when download finishes

RESOLVED FIXED

Status

SeaMonkey
Download & File Handling
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Rob Hulswit, Unassigned)

Tracking

({fixed-seamonkey1.1b})

Trunk
x86
All
fixed-seamonkey1.1b

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060816 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060816 SeaMonkey/1.5a

When a download finishes, the column with the transferred data amounts misses its final update on completion. In the URL, it currently shows 454KB of 472KB on a finished download. It is different from bug 149237 in that the size of the download is actually known (and shown during downloading)

Reproducible: Always

Steps to Reproduce:
1. Download the file http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-08-16-11-trunk/windows-xpi/langenus.xpi
2. Open the download manager
3. After completion of the download, look at the transferred column.


Actual Results:  
It shows 454KB of 472KB

Expected Results:  
It shows 472GB of 472KB

This is really confusing; the user is given contradictionary information; on the one hand the progress column says that the download is finished, but the transferred column says that it hasn't
(Reporter)

Updated

12 years ago
Version: unspecified → Trunk

Comment 1

12 years ago
I confirm your findings with Seamonkey 1.5a rv:1.9a1 build 2006081609 under XP Pro SP2.

CONFIRMING
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

12 years ago
Created attachment 234143 [details]
Screenshot of download manager after completing steps to reproduce

Progress says Finished 
while
Transferred says 470KB of 472KB

Comment 3

12 years ago
Problem also present on Gecko/20060821 SeaMonkey/1.1a, as well as the OS/2 build of 1.1a.  It's only cosmetic, but it is a regression from 1.0.x.

Flags: blocking-seamonkey1.1b?
OS: Windows 2000 → All
This is a regression from bug 273971, which was checked in into 1.8.1 partly with bug 245725.
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051218 SeaMonkey/1.5a, regressed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051220 SeaMonkey/1.5a. Checkin of bug 273971 was 20051219.

Updated

12 years ago
Blocks: 273971

Comment 6

12 years ago
I've got a fix for this. It was meant to go in as part of the patch for bug 237623, but never made it. I'll clean it up tonight and attach it here.

Comment 7

12 years ago
Created attachment 238887 [details] [diff] [review]
patch v0 - for toolkit
Attachment #238887 - Flags: review?

Comment 8

12 years ago
Created attachment 238888 [details] [diff] [review]
patch v0 - for xpfe
Attachment #238888 - Flags: superreview?(neil)
Attachment #238888 - Flags: review?(cbiesinger)

Updated

12 years ago
Attachment #238887 - Flags: review? → review?(mconnor)

Comment 9

12 years ago
Comment on attachment 238888 [details] [diff] [review]
patch v0 - for xpfe

I guess this explains why unknown sized downloads used to constantly update because it was impossible to know which was the last... biesi, should ExecuteDesiredAction use mProgress for all values, to force an update?

>+  if (aMaxTotalProgress != -1 && LL_EQ(aCurTotalProgress, aMaxTotalProgress))
I'd hope that LL_EQ(aCurTotalProgress, aMaxTotalProgress) guarantees aMaxTotalProgress != -1 ;-) In which case, you could just change the test below to delta < gInterval && LL_NE(aCurTotalProgress, aMaxTotalProgress)
Attachment #238888 - Flags: superreview?(neil) → superreview+
Comment on attachment 238888 [details] [diff] [review]
patch v0 - for xpfe

yeah, please remove he "aMaxTotalProgress != -1 && " part. Also, you can now use == instead of LL_EQ, we gave up on supporting platforms without native PRInt64. Finally, please use PRBool instead of bool (and PR_FALSE instead of false)

Please attach a new patch with those changes, thanks. Sorry for the delay.
Attachment #238888 - Flags: review?(cbiesinger) → review-
(In reply to comment #9)
> biesi, should
> ExecuteDesiredAction use mProgress for all values, to force an update?

I agree. Didn't I review a patch somewhere that did that?

Comment 12

12 years ago
(In reply to comment #11)
> I agree. Didn't I review a patch somewhere that did that?

Any of these? (I queried on attachment data contains OnProgressChange64)

https://bugzilla.mozilla.org/buglist.cgi?bug_id=83265,187483,200448,228968,237623,241972,245725,273971,288585,290648,291406,312370,326840,343921,348925

Comment 13

12 years ago
Created attachment 239993 [details] [diff] [review]
patch v1 - for toolkit
Attachment #238887 - Attachment is obsolete: true
Attachment #239993 - Flags: review?(mconnor)
Attachment #238887 - Flags: review?(mconnor)

Comment 14

12 years ago
Created attachment 239994 [details] [diff] [review]
patch v1 - for xpfe (Checked into trunk & 1.8.1 branch)

Updated.
Attachment #238888 - Attachment is obsolete: true
Attachment #239994 - Flags: review?(cbiesinger)
neil: ah. see bug 149237 comment 48, at the end. seems to have been before the 64-bit version of onProgressChange, so your query doesn't find it.
Attachment #239994 - Flags: review?(cbiesinger) → review+

Comment 16

12 years ago
Comment on attachment 239994 [details] [diff] [review]
patch v1 - for xpfe (Checked into trunk & 1.8.1 branch)

I landed this on trunk

Comment 17

12 years ago
Should this go into SeaMonkey 1.1 (on 1.8 branch)? If so, please nominate it for that by requesting approval-seamonkey1.1b?

This is no really major problem though, it's just annoying, so we won't push back a beta for it, we can still take such trivial polishing fixes (without L10n changes) after Beta and still have it in final.

Updated

12 years ago
Attachment #239994 - Flags: approval-seamonkey1.1b?

Comment 18

12 years ago
Comment on attachment 239994 [details] [diff] [review]
patch v1 - for xpfe (Checked into trunk & 1.8.1 branch)

Looks like an easy change :)
a=me for SeaMonkey 1.1b
Attachment #239994 - Flags: approval-seamonkey1.1b? → approval-seamonkey1.1b+

Comment 19

12 years ago
Comment on attachment 239994 [details] [diff] [review]
patch v1 - for xpfe (Checked into trunk & 1.8.1 branch)

Checking in (1.8.1 branch)
nsDownloadManager.cpp;
new revision: 1.111.4.4; previous revision: 1.111.4.3
done
Attachment #239994 - Attachment description: patch v1 - for xpfe → patch v1 - for xpfe (Checked into trunk & 1.8.1 branch)

Updated

12 years ago
Flags: blocking-seamonkey1.1b?
Keywords: fixed-seamonkey1.1b
Comment on attachment 239993 [details] [diff] [review]
patch v1 - for toolkit

if this still applies, please re-request review.  I'm pretty sure this is no longer needed though.
Attachment #239993 - Flags: review?(mconnor)

Comment 21

9 years ago
What needed to be fixed has been fixed for SeaMonkey 1.1 Beta. Let's mark this correctly.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.