Bug 228968 (NegativeDownload)

downloading a large file >2GB displays negative status values

VERIFIED FIXED in seamonkey1.0alpha

Status

SeaMonkey
Download & File Handling
P1
normal
VERIFIED FIXED
15 years ago
4 years ago

People

(Reporter: Spiros Ioannou, Assigned: Biesinger)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: see comment 53 before attaching more screenshots)

Attachments

(11 attachments, 3 obsolete attachments)

66.23 KB, image/jpeg
Details
15.67 KB, image/png
Details
6.85 KB, image/png
Details
14.95 KB, image/jpeg
Details
204.53 KB, image/jpeg
Details
71.56 KB, image/jpeg
Details
71.56 KB, image/jpeg
Details
45.90 KB, application/octet-stream
Details
16.15 KB, image/jpeg
Details
64.55 KB, patch
Details | Diff | Splinter Review
14.19 KB, image/jpeg
Details
(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031218
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031218

Downloading a large file (about 3GB) displays negative values for file size
(Status:xxxKb of -1173483Kb at xxxKb/sec), after a while the speed becomes
negative (-xxxKB/sec).
Here are the equivalent headers:

Date: Fri, 19 Dec 2003 16:00:30 GMT
Server: Apache/1.3.22 (Unix) Debian GNU/Linux PHP/4.1.1
X-Powered-By: PHP/4.1.1
Expires: 0
Cache-Control: private
Connection: close
Content-length: 3093319680
Content-disposition: attachment; filename="pilatos1.tar"
Content-Type: application/octet-stream




Reproducible: Always

Steps to Reproduce:
(Reporter)

Updated

15 years ago
Summary: downloading a large file ~3GB displays negative values → downloading a large file ~3GB displays negative status values

*** This bug has been marked as a duplicate of 184452 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 2

15 years ago
make this a depends... since bug 184452 could affect many places.
Status: RESOLVED → UNCONFIRMED
Component: Networking: File → Download Manager
Depends on: 184452
Resolution: DUPLICATE → ---
well, other bugs with exactly this description were marked duplicate of bug
184452 as well... *shrug*

Comment 4

15 years ago
*** Bug 230836 has been marked as a duplicate of this bug. ***

Comment 5

14 years ago
I can confirm that this happens in Mozilla 1.6 under Linux.  Please update the
OS field.

Comment 6

14 years ago
I was downloading this file:

ftp://redhat.secsup.org/pub/linux/redhat/fedora/core/test/1.91/i386/iso/FC2-test2-i386-DVD.iso

The "Transferred" and "Speed" columns became negative after approximately 40-75%
the way thru the download.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All

Comment 7

14 years ago
Created attachment 145561 [details]
Trying to download Fedora Core 2 test 2 with negative values

I tried to download this file and after ~2 GB the values became negative. The
time was that funny nearly since I started downloading.

I'm using Mozilla 1.7b .
*** Bug 241158 has been marked as a duplicate of this bug. ***

Comment 9

14 years ago
*** Bug 243122 has been marked as a duplicate of this bug. ***

Comment 10

14 years ago
*** Bug 221359 has been marked as a duplicate of this bug. ***

Comment 11

14 years ago
*** Bug 245155 has been marked as a duplicate of this bug. ***

Comment 12

14 years ago
christian: is this a dupe and/or do you want to own this bug? ;-)

i have no time to work on >2Gb file size bugs.
Keywords: helpwanted
Target Milestone: --- → Future
I'm pretty sure this is caused by the use of "long" (i.e. signed 32-bit value)
in
http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsIWebProgressListener.idl#135,
so this is probably not a dup.


hm... well, taking and targetting
Assignee: darin → cbiesinger
Keywords: helpwanted
Target Milestone: Future → mozilla1.9alpha

Comment 14

14 years ago
*** Bug 247921 has been marked as a duplicate of this bug. ***

Comment 15

14 years ago
*** Bug 251649 has been marked as a duplicate of this bug. ***

Comment 16

14 years ago
*** Bug 251828 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago
*** Bug 252457 has been marked as a duplicate of this bug. ***

Comment 18

14 years ago
*** Bug 252872 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
*** Bug 252912 has been marked as a duplicate of this bug. ***

Comment 20

14 years ago
*** Bug 254643 has been marked as a duplicate of this bug. ***

Comment 21

14 years ago
*** Bug 253956 has been marked as a duplicate of this bug. ***

Comment 22

14 years ago
*** Bug 255005 has been marked as a duplicate of this bug. ***

Comment 23

14 years ago
Created attachment 156830 [details]
Problem also occurs under Firefox 0.9 (Windows)

Notice that the dialog reports a file size of ~74Mb while it should be ~4Gb.
All the statistics are broken too.

Comment 24

14 years ago
*** Bug 257213 has been marked as a duplicate of this bug. ***

Comment 25

14 years ago
*** Bug 257266 has been marked as a duplicate of this bug. ***

Comment 26

14 years ago
Created attachment 157341 [details]
Negative status values in Firefox 0.9.3

I saw this today too, while downloading the World of Warcraft Stress Test beta
from Fileplanet.  File is 2,370,316,457 bytes.

Comment 27

14 years ago
*** Bug 257829 has been marked as a duplicate of this bug. ***

Comment 28

14 years ago
i ran into this dealing with a restore from backuppc.   the file was over 4GB,
and i wound up having to use internet explorer to download it.

this looks suspiciously like a typing problem to me.    at 2GB, it exceeds
LONG_MAX, wraps back to LONG_MIN, and continues up to zero.   when it reaches 0,
the download fails.    

i've seen the same problem on mozilla-firefox 0.8-12 from debian's testing
distribution, and on mozilla 1.4 on win2k.
whoa, it  _fails_? can you file a bug on that? this one is just about a cosmetic
problem...

please mention whether it was an http or ftp server, and it would be great if
you could find out which headers the server sent

Comment 30

14 years ago
Also in ver 1.0PR

*** Bug 261059 has been marked as a duplicate of this bug. ***
*** Bug 263591 has been marked as a duplicate of this bug. ***

Comment 33

14 years ago
Also, if the file size is sufficiently large enough (Fedora Core DVD ISO in my
case), the file size estimate is positive again, and the %s complete are being
based on that size...  so this supposed "72 MB" file (actual size is above 4 GB)
started to show % completes above 100%, then looped around to the negatives.  I
have not seen the download fail yet, but then again, there is still -565% left
on my download.
FireFox 1.0 PR under Windows XP.


Note:  The failure mentioned in here might be on a FAT32 drive, which cannot
have files larger than 4 GB in size (thus being the reason for the failure).

Comment 34

14 years ago
In re comment #33: I had the same thing occur (in #263591, a dupe of this) while
downloading Fedora Core 2 ISO DVD to an NTFS drive, which has no 4GB limit.  All
three hard drives on this (Win2K SP4) system are NTFS.

Good guess, though.  

Comment 35

14 years ago
*** Bug 265044 has been marked as a duplicate of this bug. ***

Comment 36

14 years ago
*** Bug 260686 has been marked as a duplicate of this bug. ***
*** Bug 265280 has been marked as a duplicate of this bug. ***
*** Bug 266323 has been marked as a duplicate of this bug. ***

Comment 39

14 years ago
*** Bug 266861 has been marked as a duplicate of this bug. ***

Comment 40

14 years ago
*** Bug 266996 has been marked as a duplicate of this bug. ***

Comment 41

14 years ago
*** Bug 267465 has been marked as a duplicate of this bug. ***
*** Bug 267610 has been marked as a duplicate of this bug. ***

Comment 43

14 years ago
*** Bug 267869 has been marked as a duplicate of this bug. ***

Comment 44

14 years ago
Created attachment 164856 [details]
Problem also occurs in Linux, as seen here in Mandrake 10.1 Official.
(In reply to comment #44)
> Problem also occurs in Linux, as seen here in Mandrake 10.1 Official.

indeed, that's why the OS is set to all on this bug.

Comment 46

14 years ago
*** Bug 268155 has been marked as a duplicate of this bug. ***
Depends on: 264599
Target Milestone: mozilla1.9alpha → mozilla1.8alpha6

Comment 47

14 years ago
Just had this grabbing a 2.4gb DVD image (again, Fedora)

Comment 48

14 years ago
This seems logically to simply be a matter of an signed integer wrapping around.
 We'd either need a larger integer or an unsigned integer.

Am I wrong?
an unsigned 32-bit integer is totally not worth the effort, people are already
filing bugs about files > 4 GB.

but yes. the issue is a signed 32-bit integer. the solution depends on the
bugfix for bug 264599 and involves adding a new version of a frozen interface
(nsIWebProgressListener).

Comment 50

14 years ago
*** Bug 268679 has been marked as a duplicate of this bug. ***

Comment 51

14 years ago
*** Bug 268741 has been marked as a duplicate of this bug. ***
Created attachment 165622 [details]
Also in 1.0 PR on linux

Comment 53

14 years ago
Tweaking summary to reflect that this affects files >2GB, not just files ~3GB.

General comment to all future readers of this bug:

Please don't continue to submit screenshots of a problem that we already know
occurs on all platforms (see Hardware: All / OS: All at top of page). In general
screenshots are not necessary anyway unless the bug is related to some layout
problem.

We know the problem exists, and additional evidence is not required.

Also, please don't submit/test bugs on older versions of the software. Since 1.0
has been released, please base bug reports on that, rather than 1.0 PR or (even
worse) older versions than that.
Summary: downloading a large file ~3GB displays negative status values → downloading a large file >2GB displays negative status values
Whiteboard: see comment 53 before attaching more screenshots

Comment 54

14 years ago
*** Bug 269531 has been marked as a duplicate of this bug. ***

Comment 55

14 years ago
*** Bug 269555 has been marked as a duplicate of this bug. ***

Comment 56

14 years ago
*** Bug 270397 has been marked as a duplicate of this bug. ***

Comment 57

14 years ago
The problem of negative size and speed and percentage on files over 2GB is still
present in Firefox 1.0, i upgraded fron 1.0PR and there is still that problem.
(In reply to comment #57)
> The problem of negative size and speed and percentage on files over 2GB is still
> present in Firefox 1.0, i upgraded fron 1.0PR and there is still that problem.

That's why this bug is marked NEW rather than FIXED. please see
https://bugzilla.mozilla.org/etiquette.html 1.1
Product: Browser → Seamonkey

Comment 59

14 years ago
*** Bug 272089 has been marked as a duplicate of this bug. ***
*** Bug 272315 has been marked as a duplicate of this bug. ***

Comment 61

14 years ago
*** Bug 272443 has been marked as a duplicate of this bug. ***

Comment 62

14 years ago
The length of a download file greater than 2^31 gets a length of 2^31 in the
information of the download manager.
The programmer must change the 4byte integer computing into a 6byte integer
computing, two's complement integers of 4 bytes change in negative above
2,147,483,647.
Also the speed and the time changes in a negative number 
(negative length/elapsed seconds).
I also could not save the file at the end (progres:fail, it was a 4GB ISO DVD).
Because it takes to much frustrating time I did not replicate the saving error.
inability to download is a separate bug, and that is supposed to work, although
possibly only in current 1.8alpha releases.

using a 6byte integer makes no sense... first of all, there's no datatype for
such an integer. anyway, yes, that is known...

Comment 64

14 years ago
*** Bug 274765 has been marked as a duplicate of this bug. ***

Comment 65

14 years ago
*** Bug 274978 has been marked as a duplicate of this bug. ***
*** Bug 276058 has been marked as a duplicate of this bug. ***

Comment 67

14 years ago
*** Bug 277637 has been marked as a duplicate of this bug. ***
*** Bug 277668 has been marked as a duplicate of this bug. ***

Comment 69

14 years ago
*** Bug 277752 has been marked as a duplicate of this bug. ***

Comment 70

14 years ago
*** Bug 277786 has been marked as a duplicate of this bug. ***
Isn't this bug component Core i/o Seamonkey ?
Most of the dupes are from Firefox .

Comment 72

14 years ago
*** Bug 277902 has been marked as a duplicate of this bug. ***
*** Bug 277991 has been marked as a duplicate of this bug. ***
*** Bug 278015 has been marked as a duplicate of this bug. ***
*** Bug 278270 has been marked as a duplicate of this bug. ***
*** Bug 278795 has been marked as a duplicate of this bug. ***
*** Bug 278898 has been marked as a duplicate of this bug. ***
*** Bug 278926 has been marked as a duplicate of this bug. ***
*** Bug 279419 has been marked as a duplicate of this bug. ***
*** Bug 279468 has been marked as a duplicate of this bug. ***
*** Bug 279477 has been marked as a duplicate of this bug. ***

Comment 82

14 years ago
*** Bug 279706 has been marked as a duplicate of this bug. ***

Comment 83

14 years ago
Wow, this bug is averaging a dupe every three days. I, for one, will be happy
when this bug is fixed - if not to stop the Bugzilla traffic on such a bug with
so much visibility.

Comment 84

14 years ago
*** Bug 279995 has been marked as a duplicate of this bug. ***
*** Bug 280270 has been marked as a duplicate of this bug. ***

Comment 86

14 years ago
*** Bug 280314 has been marked as a duplicate of this bug. ***

Comment 87

14 years ago
*** Bug 280327 has been marked as a duplicate of this bug. ***

Comment 88

14 years ago
Created attachment 172889 [details]
all values negative (speed of download too) - Mozilla 1.7.5

How you can see i found this problem for all 3 values you can see in download
manager. i think that it's it with the size about 2GB, but how you can see,
too, is the problem with the speed of downloads too... I have DSL with 2MBit/s.

Comment 89

14 years ago
Created attachment 172890 [details]
all values negative (speed of download too) - Mozilla 1.7.5

How you can see i found this problem for all 3 values you can see in download
manager. i think that it's it with the size about 2GB, but how you can see,
too, is the problem with the speed of downloads too... I have DSL with 2MBit/s.

Comment 90

14 years ago
*** Bug 280757 has been marked as a duplicate of this bug. ***

Comment 91

14 years ago
In comment 49, Christian mentioned that bug 264599 needed to be fixed first. 
Given that it is, shouldn't it be possible to move along with this bugfix?

What is the difference with bug 184452 from 264599 that allows it to continue to
block this?

Comment 92

14 years ago
Created attachment 173157 [details]
Firefox 1.0 on Windows with a over-2Gb download....

This shows a firefox download of a over 2Gb file, displaying negative values in
status. The file was downloaded ok according to MD5 checksum.
bug 184452 includes frozen interfaces as well

could you guys stop attaching screenshots finally?

thank you for verifying that the file did download ok, though.

Comment 94

14 years ago
*** Bug 281039 has been marked as a duplicate of this bug. ***

Comment 95

14 years ago
*** Bug 281086 has been marked as a duplicate of this bug. ***
*** Bug 281303 has been marked as a duplicate of this bug. ***
*** Bug 281739 has been marked as a duplicate of this bug. ***
*** Bug 281805 has been marked as a duplicate of this bug. ***
*** Bug 282119 has been marked as a duplicate of this bug. ***

Comment 100

14 years ago
*** Bug 282210 has been marked as a duplicate of this bug. ***

Comment 101

14 years ago
I'd like it to be fixed by Firefox 1.1 => blocking aviary 1.1 ?
Flags: blocking-aviary1.1?

Comment 102

14 years ago
Well Moz 1.8alpha6 has past. What's the new target milestone for this bug?

I too vote for blocking 1.1 aviary, but I haven't seen anything patches yet.
Target Milestone: mozilla1.8alpha6 → mozilla1.8beta2
*** Bug 283845 has been marked as a duplicate of this bug. ***

Comment 104

14 years ago
*** Bug 283673 has been marked as a duplicate of this bug. ***

Comment 105

14 years ago
*** Bug 284459 has been marked as a duplicate of this bug. ***
Priority: -- → P1

Comment 106

14 years ago
Created attachment 177007 [details]
Firefox v1.0.1 shows as negative, after 2GB download.

Here is another proof that this bug exists in Firefox 1.0.1

Comment 107

14 years ago
(In reply to comment #106)
> Here is another proof that this bug exists in Firefox 1.0.1

Yes, this bug is still open as you clearly can see in its status. Please stop
attaching screenshots (8 now). 

Comment 108

14 years ago
*** Bug 286549 has been marked as a duplicate of this bug. ***

Comment 109

13 years ago
*** Bug 286585 has been marked as a duplicate of this bug. ***
*** Bug 286641 has been marked as a duplicate of this bug. ***
Created attachment 178062 [details] [diff] [review]
patch

- I haven't checked yet whether this compiles on mac
- neither on photon (and I won't be able to)
- camino will need an extra patch, from someone who knows objective c (i.e. not
me)

- the patch requires the patches from the depending bugs to even compile

(unfortunately I was not able to test HTTP, since apache somewhat failed to
support files > 4 GB :-/ )
Attachment #178062 - Flags: review?(bzbarsky)

Comment 112

13 years ago
*** Bug 287241 has been marked as a duplicate of this bug. ***

Comment 113

13 years ago
*** Bug 287427 has been marked as a duplicate of this bug. ***
*** Bug 287479 has been marked as a duplicate of this bug. ***
*** Bug 287958 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Target Milestone: mozilla1.8beta2 → ---
Target Milestone: --- → Seamonkey1.0alpha

Comment 116

13 years ago
Why not use double-precision floating point or higher for potentially large
variables like this? A GB is 10 digits, while ordinary double-precision handles
16 digits as I recall.
I really don't see what the inexact double type gives us over PRUint64,
especially as it is not at all guaranteed that adding to a double will change
its value. 2**63 bytes should really suffice for all practical purposes. (note:
a double usually takes 8 bytes, just like a PRUint64)
Comment on attachment 178062 [details] [diff] [review]
patch

>Index: camino/src/download/nsDownloadListener.mm

>+  // XXX truncates 64-bit to 32-bit

File a followup bug on this, please.

>Index: embedding/browser/cocoa/src/nsDownloadListener.mm

>+  // XXX truncates 64-bit to 32-bit

Same.

>Index: embedding/browser/photon/src/EmbedDownload.cpp

And here.

>Index: embedding/browser/powerplant/source/UDownload.cpp

And here.

>Index: toolkit/components/downloads/src/nsDownloadManager.cpp

>+    nsCOMPtr<nsIDownload> dialog = do_QueryInterface(aSubject);

Rename the variable to |download| too?

>Index: toolkit/components/downloads/src/nsDownloadProxy.h

>+  NS_IMETHODIMP OnProgressChange64(nsIWebProgress *aWebProgress,

Should this assert if mInner doesn't QI to nsIWebProgressListener2 and is
non-null?  Or should it just fall back to using OnProgressChange() on the
nsIWebProgressListener interface?

>Index: uriloader/base/nsIWebProgressListener.idl
>+   * NOTE: If the object also implements nsIWebProgressListener2 and the caller
>+   * supports that interface

I'd use "knows about that interface", not "supports that interface"....

>Index: uriloader/base/nsIWebProgressListener2.idl
>+  /**
>+   * Notification that the progress has changed for one of the 
requests

Maybe just document here that this is identical to
nsIWebProgressListener.onProgressChange with an @see and all, instead of
copying all the information?  Either way, add an @see here, please.

>Index: uriloader/exthandler/nsExternalHelperAppService.cpp

>-  { "application/xhtml+xml", "xht" }
>+  { "application/xhtml+xml", "xht" },

No, I don't think you want that change... (it'll cause compiler warnings,
iirc).

>Index: xpfe/components/download-manager/src/nsDownloadManager.cpp

>       internalListener->OnProgressChange(aWebProgress, aRequest, aCurSelfProgress, aMaxSelfProgress,
>-                                          aCurTotalProgress, aMaxTotalProgress, this);
>+                                           aCurTotalProgress, aMaxTotalProgress, this);

Weird indent....

r=bzbarsky with those nits fixed.
Attachment #178062 - Flags: review?(bzbarsky) → review+
Created attachment 179516 [details] [diff] [review]
additional patch for camino

this is an additional patch that's required so that camino still builds
Attachment #179516 - Flags: review?(bzbarsky)
I'll file those followup bugs once I checkin the patch.

(In reply to comment #118)
> >+  NS_IMETHODIMP OnProgressChange64(nsIWebProgress *aWebProgress,
> 
> Should this assert if mInner doesn't QI to nsIWebProgressListener2 and is
> non-null?  Or should it just fall back to using OnProgressChange() on the
> nsIWebProgressListener interface?

Nah, assert is ok... actually mInner is an nsIDownload, which (indirectly)
inherits from nsIWebProgressListener2 anyway; so, the QI is not needed at all.
I'll file a bug to remove the QIs (replace them with nullchecks of mInner)


> >-  { "application/xhtml+xml", "xht" }
> >+  { "application/xhtml+xml", "xht" },
> 
> No, I don't think you want that change... (it'll cause compiler warnings,
> iirc).

oops. must be a leftover from a now-removed local change.


I'll fix the other issues in the next version of the patch...
> Rename the variable to |download| too?

download would later be shadowed by another variable with the same name... I'll
pick |dl| here.
>Maybe just document here that this is identical to
>nsIWebProgressListener.onProgressChange with an @see and all, instead of
>copying all the information?  Either way, add an @see here, please.

I find it useful that one need not check different files to understand this
function... I'll add an @see and a note that this function is basically identical.
Created attachment 179531 [details] [diff] [review]
patch v2

(includes the camino patch)
Attachment #178062 - Attachment is obsolete: true
Attachment #179516 - Attachment is obsolete: true
Attachment #179531 - Flags: superreview?(darin)

Comment 124

13 years ago
Comment on attachment 179531 [details] [diff] [review]
patch v2

>Index: embedding/browser/powerplant/source/UDownload.cpp

>+NS_IMPL_ISUPPORTS4(CDownload, nsIDownload, nsITransfer, nsIWebProgressListener, nsIWebProgressListener2)

nit: please wrap long lines


>Index: embedding/components/ui/helperAppDlg/nsHelperAppDlg.js

>+        onProgressChange64: function( aWebProgress,
>+                                      aRequest,
>+                                      aCurSelfProgress,
>+                                      aMaxSelfProgress,
>+                                      aCurTotalProgress,
>+                                      aMaxTotalProgress ) {
>+        },
>+

Does this guy need a QI implementation?


>Index: embedding/components/webbrowserpersist/src/nsWebBrowserPersist.h

> #include "nsIWebProgressListener.h"
>+#include "nsIWebProgressListener2.h"

nit: you can just remove the first #include


There was some code where you use nsUint64 when converting
from PRInt64 to PRInt32.  Why not use nsInt64 in those cases?


>Index: toolkit/components/downloads/src/nsDownloadProxy.h

>+    nsCOMPtr<nsIWebProgressListener2> listener = do_QueryInterface(mInner);
>+    if (listener)
>+      return listener->OnProgressChange64(aWebProgress, aRequest, aCurSelfProgress,
>+                                          aMaxSelfProgress, aCurTotalProgress, aMaxTotalProgress);

nit: break long lines


>Index: uriloader/base/nsIWebProgressListener.idl

>+   * NOTE: If the object also implements nsIWebProgressListener2 and the caller
>+   * knows about that interface, this function will not be called. Instead,
>+   * nsIWebProgressListener2::onProgressChange64 will be called.
>    */
>   void onProgressChange(in nsIWebProgress aWebProgress,

This is good documentation, but since nsIWebProgressListener2 really needs
to be marked frozen.


>Index: uriloader/exthandler/nsExternalHelperAppService.cpp

> NS_IMETHODIMP nsExternalAppHandler::OnStartRequest(nsIRequest *request, nsISupports * aCtxt)
...
>+  // Get content length
>+  nsresult rv;
>+  nsCOMPtr<nsIPropertyBag2> props(do_QueryInterface(request, &rv));
>+  if (props) {
>+    rv = props->GetPropertyAsInt64(NS_CHANNEL_PROP_CONTENT_LENGTH,
>+                                   &mContentLength.mValue);
>+  }
>+  // If that failed, ask the channel
>+  if (NS_FAILED(rv) && aChannel) {
>+    PRInt32 len;
>+    aChannel->GetContentLength(&len);
>+    mContentLength = len;
>+  }
>+

Hmm... we're getting the content-length here so we can use it
to drive OnProgressChange64 calls.  But, it seems like we should
really just be observing nsIProgressSink::OnProgress calls from
the channel.  Maybe that is hard to do for some reason?  Maybe
file a bug for that approach?

At any rate, I definitely like your idea of moving this logic into
a NS_GetContentLength function implemented inline in nsNetUtil.h


sr=darin with nits
Attachment #179531 - Flags: superreview?(darin) → superreview+
(In reply to comment #124)
> Does this guy need a QI implementation?

It shouldn't... it's passed to setWebProgressListener, which takes an
nsIWebProgressListener2 argument, so xpconnect should do this for me.

> There was some code where you use nsUint64 when converting
> from PRInt64 to PRInt32.  Why not use nsInt64 in those cases?

It converts from PRUint64, not PRInt64...

> >Index: toolkit/components/downloads/src/nsDownloadProxy.h
> nit: break long lines

Many lines here are over 80 chars. but sure.

> Hmm... we're getting the content-length here so we can use it
> to drive OnProgressChange64 calls.  But, it seems like we should
> really just be observing nsIProgressSink::OnProgress calls from
> the channel.  Maybe that is hard to do for some reason?  Maybe
> file a bug for that approach?

That's not so trivial... this is not directly a channel's listener, and the
progress event sink is something else, probably docshell or docloader. I'll file
a bug on this. 

> At any rate, I definitely like your idea of moving this logic into
> a NS_GetContentLength function implemented inline in nsNetUtil.h

Yeah, I'll convert the code here to that probably in bug 289170
Created attachment 179779 [details] [diff] [review]
final patch
Attachment #179531 - Attachment is obsolete: true
checked in. firefox and seamonkey should work.

bug 288585 is for camino
bug 289214 for embedding/browser/cocoa
bug 289216 for photon
bug 289218 for powerplant

Bug 289219 for not QIing mInner in nsDownloadProxy (toolkit)
Bug 289220 for not QIing mInner in nsDownloadProxy (xpfe)

Bug 289221 for making exthandler an nsIProgressEventSink.

Marking FIXED!
No longer blocks: 289214, 289216, 289218
Status: NEW → RESOLVED
Last Resolved: 15 years ago13 years ago
Resolution: --- → FIXED
undoing accidental dependency changes... sorry for the bugspam (I blame
bugzilla! it should have told me about midair)
Blocks: 289214, 289216, 289218

Comment 129

13 years ago
*** Bug 289261 has been marked as a duplicate of this bug. ***
*** Bug 289942 has been marked as a duplicate of this bug. ***

Comment 131

13 years ago
*** Bug 290698 has been marked as a duplicate of this bug. ***
*** Bug 290931 has been marked as a duplicate of this bug. ***
just let me know if this ever goes onto the 17branch so that we can pick it up
for camino 0.8.x builds.
*** Bug 291617 has been marked as a duplicate of this bug. ***

Comment 135

13 years ago
*** Bug 263967 has been marked as a duplicate of this bug. ***
*** Bug 292873 has been marked as a duplicate of this bug. ***

Comment 137

13 years ago
*** Bug 293406 has been marked as a duplicate of this bug. ***
*** Bug 293952 has been marked as a duplicate of this bug. ***
*** Bug 294072 has been marked as a duplicate of this bug. ***
*** Bug 294291 has been marked as a duplicate of this bug. ***

Comment 141

13 years ago
*** Bug 294380 has been marked as a duplicate of this bug. ***
*** Bug 295216 has been marked as a duplicate of this bug. ***

Comment 143

13 years ago
*** Bug 295426 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 163993

Updated

13 years ago
No longer blocks: 163993
*** Bug 296067 has been marked as a duplicate of this bug. ***
*** Bug 296612 has been marked as a duplicate of this bug. ***
*** Bug 297197 has been marked as a duplicate of this bug. ***
*** Bug 297241 has been marked as a duplicate of this bug. ***
Alias: NegativeDownload
*** Bug 297591 has been marked as a duplicate of this bug. ***
*** Bug 297716 has been marked as a duplicate of this bug. ***
*** Bug 298404 has been marked as a duplicate of this bug. ***

Comment 151

13 years ago
*** Bug 298776 has been marked as a duplicate of this bug. ***

Comment 152

13 years ago
*** Bug 299271 has been marked as a duplicate of this bug. ***
*** Bug 299755 has been marked as a duplicate of this bug. ***
*** Bug 300652 has been marked as a duplicate of this bug. ***
*** Bug 301150 has been marked as a duplicate of this bug. ***

Comment 156

13 years ago
*** Bug 302056 has been marked as a duplicate of this bug. ***
*** Bug 303302 has been marked as a duplicate of this bug. ***

Comment 158

13 years ago
*** Bug 303632 has been marked as a duplicate of this bug. ***

Comment 159

13 years ago
*** Bug 304161 has been marked as a duplicate of this bug. ***

Comment 160

13 years ago
*** Bug 304253 has been marked as a duplicate of this bug. ***

Comment 161

13 years ago
*** Bug 304289 has been marked as a duplicate of this bug. ***

Comment 162

13 years ago
*** Bug 304349 has been marked as a duplicate of this bug. ***
*** Bug 305101 has been marked as a duplicate of this bug. ***
*** Bug 305219 has been marked as a duplicate of this bug. ***
*** Bug 305348 has been marked as a duplicate of this bug. ***
*** Bug 306141 has been marked as a duplicate of this bug. ***
*** Bug 306152 has been marked as a duplicate of this bug. ***
*** Bug 306158 has been marked as a duplicate of this bug. ***
*** Bug 306234 has been marked as a duplicate of this bug. ***
No longer blocks: 306256
*** Bug 306256 has been marked as a duplicate of this bug. ***
*** Bug 306365 has been marked as a duplicate of this bug. ***
*** Bug 306490 has been marked as a duplicate of this bug. ***

Comment 173

13 years ago
*** Bug 307116 has been marked as a duplicate of this bug. ***
*** Bug 307125 has been marked as a duplicate of this bug. ***

Comment 175

13 years ago
*** Bug 307356 has been marked as a duplicate of this bug. ***
*** Bug 308022 has been marked as a duplicate of this bug. ***
*** Bug 308378 has been marked as a duplicate of this bug. ***
*** Bug 308722 has been marked as a duplicate of this bug. ***

Comment 179

13 years ago
*** Bug 309151 has been marked as a duplicate of this bug. ***
*** Bug 309319 has been marked as a duplicate of this bug. ***
*** Bug 309711 has been marked as a duplicate of this bug. ***
*** Bug 309980 has been marked as a duplicate of this bug. ***

Comment 183

13 years ago
Sorry, slow today - not only the minus sign but it's counting down not up.
*** Bug 310658 has been marked as a duplicate of this bug. ***
*** Bug 310689 has been marked as a duplicate of this bug. ***

Comment 186

13 years ago
*** Bug 311344 has been marked as a duplicate of this bug. ***
*** Bug 311608 has been marked as a duplicate of this bug. ***
*** Bug 312005 has been marked as a duplicate of this bug. ***

Comment 189

13 years ago
I'm sure I'm reading this wrong, but it looks like this thing was fixed forever
ago. People continue to experience the bug, make dupe reports, and have them
closed as dupes. Firefox 1.0.7 is showing me exactly this bug, and it was built
last month.

Is this bug fixed but somehow not rolled into ff 1.0.7? Should I go play with
nightlies?

What the dilly-yo?
(In reply to comment #189)
> Is this bug fixed but somehow not rolled into ff 1.0.7?

Correct. This bug is fixed for Firefox 1.5 and Seamonkey 1.0, and will not be
fixed in the Firefox 1.0.x series. You can download nightlies or betas if you
really want the fix.
*** Bug 313095 has been marked as a duplicate of this bug. ***
*** Bug 313339 has been marked as a duplicate of this bug. ***

Comment 193

13 years ago
*** Bug 313405 has been marked as a duplicate of this bug. ***
*** Bug 313808 has been marked as a duplicate of this bug. ***
*** Bug 314569 has been marked as a duplicate of this bug. ***
*** Bug 320136 has been marked as a duplicate of this bug. ***

Comment 197

13 years ago
Created attachment 207710 [details]
negative values when downloading large (>2GB) file
*** Bug 331988 has been marked as a duplicate of this bug. ***

Comment 199

12 years ago
*** Bug 332871 has been marked as a duplicate of this bug. ***
*** Bug 338669 has been marked as a duplicate of this bug. ***

Comment 201

12 years ago
*** Bug 355854 has been marked as a duplicate of this bug. ***

Comment 202

12 years ago
Could this be same bug as bug #265441?

Updated

12 years ago
Duplicate of this bug: 371627
Duplicate of this bug: 380273
Checked different locations with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4pre) Gecko/20070508 BonEcho/2.0.0.4pre and all works fine. v.
Status: RESOLVED → VERIFIED

Updated

9 years ago
Duplicate of this bug: 216043
You need to log in before you can comment on or make changes to this bug.