Closed Bug 149237 (1kb) Opened 23 years ago Closed 15 years ago

Transferred value is incorrect/wrong ("1KB of 1KB") after downloading file with unknown size

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: axlrey, Unassigned)

References

Details

(Keywords: polish)

Attachments

(4 obsolete files)

When size of file is unknown during download it shows in Transferred column "NNN KB of ???? KB" - which is ok. But when download is finished it shows "1 KB of 1 KB". Expected : to show real number of KB transferred for this file. Don't know how to make a testcase. I have an online documentum account and when I'm downloading from there the file size always unknown.
I have this problem too, confirming and moving to NEW (using a nightly build from roughtly Aug 10, 2002 on win98) Sorry but i cannot tell you the sever from which i was downloading. Any download of unknown size seems to do it. This is definately reproducable. Adding myself to the CC list, need to check this on linux too.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 155391 has been marked as a duplicate of this bug. ***
*** Bug 165386 has been marked as a duplicate of this bug. ***
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910" The bug is still there. The file is transfered correctly, which is the most important; BUT, it *does* "frighten" the user by making him believe the transfer went wrong ! Please, make it work as expected; or, in the meantime, make it show "done" (so the user would check) or something instead of the wrong size ! Thanks :-)
I've had the same problem with Build 2002091014 (think it's 1.2a) on a Win98 SE machine. It happens for any file downloaded from my mail server (I'm using IMAP) Each time I want to save a mail's attachment it downloads fine but writes 1KB when it is finished. I also thought my download had went wrong when it happen.
I have 1.2a running on Windows XP. It shows the downloaded amount correctly (500/??? KB, then 535/??? KB) but when it completes, it shows just 1 KB
QA Contact: sairuh → petersen
*** Bug 172935 has been marked as a duplicate of this bug. ***
I think this bug is related to speed of download but not to "unknown size". Having fast connection I often get "1Kb of 1Kb" reports on large files with known size. My impression is that this happens in case when downloading is done within several (2-3) seconds.
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 175862 has been marked as a duplicate of this bug. ***
*** Bug 177937 has been marked as a duplicate of this bug. ***
*** Bug 178872 has been marked as a duplicate of this bug. ***
*** Bug 179383 has been marked as a duplicate of this bug. ***
*** Bug 181450 has been marked as a duplicate of this bug. ***
*** Bug 179441 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
*** Bug 184112 has been marked as a duplicate of this bug. ***
Severity: minor → normal
Summary: Transferred value is incorrect after downloading file with unknown size → Transferred value is incorrect/wrong (1KB of 1KB) after downloading file with unknown size
*** Bug 186845 has been marked as a duplicate of this bug. ***
*** Bug 187078 has been marked as a duplicate of this bug. ***
*** Bug 195259 has been marked as a duplicate of this bug. ***
*** Bug 195899 has been marked as a duplicate of this bug. ***
*** Bug 196772 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] Bug still there.
I am Using the 1.3 final and have a DSL Broadband Connection. I can back up Max Alekseyev's idea of the fast Downloads. For me this Bug appears if I download small files (e.g. 400kb)
I am Using the 1.3 final and have a DSL Broadband Connection. I can back up Max Alekseyev's idea of the fast Downloads. For me this Bug appears if I download small files (e.g. 400kb)
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401] Bug still there. (with v1.3 profile, at least) Any hope to see the 'mozilla1.3' Keyword replaced by the 'mozilla1.4beta' Target Milestone ? (I'm not asking for 'blocking1.4b' Flag yet: maybe for v1.4 !?)
One easy way to see this occur is to right click a link to an HTML page, and tell it to "Save Line Target As..." This always comes up as 1KB of 1KB, regardless of the actual size of the HTML.
I don't think this bug has to do with the connection speed or the size of the file itself. I think it's purely a function of whether the Download Manager (DM) knows the size of the file. I have an ADSL connection, and I download a lot. I tested like this: I downloaded a mail attachment from my Yahoo mail account. DM registers Unknown file size: "NNN KB of ???? KB". I then saved the same file to my Yahoo briefcase account directly (using the web interface). DM registers correctly 946KB of 946KB. It didn't take the file too long to download, but it did take more than 5 seconds. The bug also happens on much smaller files, and I've also had it occur for a 5MB download, which I think precludes it being a timing issue. I don't really have a way to test large downloads (say > 50MB), but I'm fairly certain the same bug happens to them too. I'm adding myself to the CC list.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401] Allways reproductible testcase(s) (based on previous reports): By using "Save Page As...": (I'm using the "Web Page, xxx only" type, but it doesn't matter, does it ?) *<about:config> ('Unknown' size): about config.xul, 3 KB (3.429) [sizes with my profile] *<about:> ('Unknown' size): About.xhtml, 4 KB (3.657) *<chrome://global/content/logo.gif> ('Unknown' size): logo.gif, 9 KB (9.460) *<http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.4a/mozilla-win32-1.4a-installer.exe> : mozilla-win32-1.4a-installer.exe, 218 KB (222.928) *(<about:blank> and <about:cache>: can't say because real size < 1 KB) *<http://mozilla.org/images/mozilla-banner.gif> (4.500): mozilla-banner.gif, 1 KB (4.500) *<http://www.mozilla.org/> (17.796): mozilla.org.html, 1 KB (17.796) *<http://www.mozilla.org/releases/> (120.199): Releases.html, 1 KB (120.199) *Same bug by first going to <http://www.mozilla.org/>, then using 'Save Link Target As...' (on 'Download' of the latest release (v1.4a now)): the size increases during the transfer, but returns to 1 KB after the end of it. Notice that the 'downloads.rdf' file is also affected (not only the UI), as in [ <RDF:Description about="X:\CG_V2000P\About.xhtml" NC:Name="About.xhtml" NC:ProgressMode="none" NC:StatusText="Finished" NC:Transferred="4KB of 4KB"> <NC:URL resource="about:"/> <NC:File resource="X:\CG_V2000P\About.xhtml"/> <NC:DownloadState NC:parseType="Integer">1</NC:DownloadState> <NC:ProgressPercent NC:parseType="Integer">100</NC:ProgressPercent> </RDF:Description> ] Which of the RDF file or UI influences the other one ? Or is there a common/root external source ? Could it be that the RDF file is written at the beginning only with unknown/1KB size, then the UI only is updated, then the UI read back from the RDF file ? NB: The UI update is done by <http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/src/nsDownloadProgressListener.js#76>. ***** "Related" but not same bug: Notice that, when the size is only 1 character long, an extra space is inserted after "of", as in "4KB of 4KB" (and obviously the "1KB of 1KB" bug) !
Summary: Transferred value is incorrect/wrong (1KB of 1KB) after downloading file with unknown size → Transferred value is incorrect/wrong ("1KB of 1KB") after downloading file with unknown size
Addition to comment 27: ***** a) NB: It's the first time that I try to look at such code(s) ... (and wondering why the .js code is so similar to the "// nsIWebProgressListener" part in the .cpp code !?). The update during tranfer seems to be: (UI) http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/src/nsDownloadProgressListener.js#177 see also http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/src/nsDownloadManager.cpp#1052 and (RDF) http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/src/nsDownloadManager.cpp#392 ***** b) (a part of) This bug could be a result of http://lxr.mozilla.org/seamonkey/source/xpfe/components/download-manager/src/nsDownloadManager.cpp#1217 (-1219) but the cause would be that 'mMaxBytes' value is still '0' (set initialy at line 939). ***** c) Then, the only (other) place where 'mMaxBytes' is updated is line 1087. This may not be the current bug, but it seems odd to have [ 1086 mCurrBytes = (PRInt32)((PRFloat64)aCurTotalProgress / 1024.0 + .5); 1087 mMaxBytes = (PRInt32)((PRFloat64)aMaxTotalProgress / 1024 + .5); ] The two lines should have the same '1024.0' (or '1024'), shouldn't they ? (In the .js, it's '1024', for what it's worth.) Should I attach a patch (which solution ?) for this ? ***** d) I suggest (what I believe) another (tiny) speed improvement, more like line 135 of .js, may be a little more risky, but I don't think so: Move the line 1087 after line 1082 (adding brackets): *aMaxTotalProgress = -1: mMaxBytes already has a '0' (= initial) value, no need to compute it again. *aMaxTotalProgress = 0: mMaxBytes is '.5', rounded to '0' or '1' (?), by current code; it would remain at '0' with this modification, but line 1217 would take care of it later. *aMaxTotalProgress > 0: mMaxBytes new value is still computed. Should I attach a patch for this ? ***** e) I don't know how to find where theses functions are called, to see where the 'aMaxTotalProgress' value is set :-( Help !
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507] Bug still there. (with v1.3 profile, at least) (And confirming on W2K.)
*** Bug 205513 has been marked as a duplicate of this bug. ***
Alias: 1kb
Keywords: mozilla1.3 → polish
*** Bug 209178 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916] (v1.5rc1) (W98SE) Bug still there.
*** Bug 221084 has been marked as a duplicate of this bug. ***
*** Bug 188545 has been marked as a duplicate of this bug. ***
I'm getting this too. Any non-resumable download (not that the download manager can resume, as far as I know, but if the server doesn't allow resuming, this happens), the end result when the file finishes will always say 1 kb of 1 kb. I am pleased to see the download progress and transfer rate update like 30 times per second in this case though. It allieviates the lack of entertainment from the unestimatable progress bar. :p.
*** Bug 244941 has been marked as a duplicate of this bug. ***
*** Bug 245286 has been marked as a duplicate of this bug. ***
I also have this bug with Mozilla 1.7final. I've downloaded this file http://support.fujitsu-siemens.de/Treiber/drvupload.asp?DRV=663&Info=Download (a part of a driver, 4305583 bytes) with ISDN. It takes forever. So I'm sure it has nothing to do with speed or fast downloading ;-) It probably has to do with that the size of the download is not initially known and not updated after the download has finished. So the amount of data being received should be counted by the method/function/modules which actually downloads the stuff, I suppose.
Bug still there in 1.7.2 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 To test, try to download a SoftPAQ from HP, e.g. http://h18007.www1.hp.com/support/files/Armada/us/download/10534.html
Still there in 1.7.3, as well... Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a4) Gecko/20040914 Bug still there.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 Bug also seen here with my dialup connection. An example download below: ftp://ftp.dante.de/tex-archive/macros/latex/contrib/a0poster.tar.gz
Product: Browser → Seamonkey
Attached patch Patch for two files. (obsolete) — — Splinter Review
After more than two years ( maybe these bugs are even older ) a solution is found. :-) Indeed the attached small patches fix three different behaviours. - 1 KB of 1 KB is displayed if real size is unknown - If real size is unknown the CPU load goes up to 100 %, depending of speed of connection. - Wrong size is displayed ( alway 100 % ) if download has been aborted by remote host. But I must admit, I'm not completly satisfied with the results. First, the behaviour has changed slightly. Download sizes below 512 bytes are rounded downwards to 0 KB. I think this is better than rounding up zero bytes as 1 KB. Due to the fact the size is only measured in Kilobytes we have these types of rounding errors. A better solution is counting them exactly as bytes. This is done in the caller of nsDownload::OnProgressChange but not in nsDownload::OnProgressChange itself. He folks, this is ugly : The upper layer ( in nsExternalHelperAppService ) has 32 bit quantities and counts in bytes, the lower layer counts in kilobytes and uses 64 bit quantities. Well, I should volunteer to change this.
Comment on attachment 170780 [details] [diff] [review] Patch for two files. Neil: Could you have a look at comment 43 too... Thanks.
Attachment #170780 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 170780 [details] [diff] [review] Patch for two files. Looks reasonable but biesi needs to see this.
Attachment #170780 - Flags: review?(neil.parkwaycc.co.uk) → review?(cbiesinger)
(In reply to comment #45) > (From update of attachment 170780 [details] [diff] [review] [edit]) > Looks reasonable but biesi needs to see this. I guess that I'd like the issues raised by Andreas to be solved, now that he has provided a good starting point, but it's not for me to say.
Comment on attachment 170780 [details] [diff] [review] Patch for two files. why this change: - if (LL_CMP(delta, <, INTERVAL) && aMaxTotalProgress != -1 && aCurTotalProgress < aMaxTotalProgress) + if (LL_CMP(delta, <, INTERVAL) ) why are you removing the following code? I think it's still desired? - // Files less than 1Kb shouldn't show up as 0Kb. - if (mMaxBytes==0) - mMaxBytes = 1; - mCurrBytes = mMaxBytes; - mPercentComplete = 100; nsExternalHelperAppService.cpp - mWebProgressListener->OnProgressChange(nsnull, nsnull, mContentLength, mContentLength, mContentLength, mContentLength); + mWebProgressListener->OnProgressChange(nsnull, nsnull, mProgress, mContentLength, mProgress, mContentLength); why not pass mProgress for all values?
(In reply to comment #47) > (From update of attachment 170780 [details] [diff] [review] [edit]) > why this change: > - if (LL_CMP(delta, <, INTERVAL) && aMaxTotalProgress != -1 && > aCurTotalProgress < aMaxTotalProgress) > + if (LL_CMP(delta, <, INTERVAL) ) This addresses the second part, reducing the CPU load for unknown sizes. Updates should occure only after a certain time, not if the size is unknown, right ? > why are you removing the following code? I think it's still desired? > - // Files less than 1Kb shouldn't show up as 0Kb. > - if (mMaxBytes==0) > - mMaxBytes = 1; > - mCurrBytes = mMaxBytes; > - mPercentComplete = 100; Nohhh !!! If you put mCurrBytes = mMaxBytes; mPercentComplete = 100; back, you alway get the lie that you are 100% complete, no matter what happened. Rounding up towards 1 KB is useful, we should put it back in once we are 64 bit ready. Them we no longer need to round internally. > nsExternalHelperAppService.cpp > - mWebProgressListener->OnProgressChange(nsnull, nsnull, mContentLength, > mContentLength, mContentLength, mContentLength); > + mWebProgressListener->OnProgressChange(nsnull, nsnull, mProgress, > mContentLength, mProgress, mContentLength); > > why not pass mProgress for all values? This is wrong, too. You would get a response like 375 KB of 375 KB, which may be wrong if the real size is unknown and an error happens.. 375 KB of 0 KB is much more informative, IMHO. We simply do not know the real size if the server does provide it for us, thus we should not claim to know it.
(In reply to comment #48) > This addresses the second part, reducing the CPU load for unknown sizes. > Updates should occure only after a certain time, not if the size is unknown, > right ? ah, yeah - that makes sense. > Nohhh !!! > If you put [...] back, you alway get the lie that you are 100% complete, no matter what happened. > Rounding up towards 1 KB is useful, we should put it back in once we are 64 bit > ready. Them we no longer need to round internally. but it seems to me that this code: - if (mMaxBytes==0) - mMaxBytes = 1; Is needed in any case, no? Hm... Well, it may need to change to < 1024 or something, but it would still be desired, right? (bug 273971 might interest you, btw) > This is wrong, too. You would get a response like 375 KB of 375 KB, which > may be wrong if the real size is unknown and an error happens.. > 375 KB of 0 KB is much more informative, IMHO. We simply do not know the real > size if the server does provide it for us, thus we should not claim to know it. OK, I see what you mean, but consider the case that no error occured. For those cases you do want "375 KB or 375 KB", instead of the nonsense value "375 KB of 0 KB".
Depends on: 273971
(In reply to comment #49) >consider the case that no error occured. For those cases you do want >"375 KB of 375 KB", instead of the nonsense value "375 KB of 0 KB". Actually if the content length is unknown I'd rather see "375 KB".
(In reply to comment #49) > (In reply to comment #48) > > Nohhh !!! > > If you put [...] back, you alway get the lie that you are 100% complete, no > matter what happened. > > Rounding up towards 1 KB is useful, we should put it back in once we are 64 bit > > ready. Them we no longer need to round internally. > > but it seems to me that this code: > - if (mMaxBytes==0) > - mMaxBytes = 1; > Is needed in any case, no? Hm... Well, it may need to change to < 1024 or > something, but it would still be desired, right? Yes, it is a good idea not to change the behaviour if there is no need for it. > (bug 273971 might interest you, btw) Hmm, well. From a technical point of view, yes, a good idea. I really don't mind if it is in bytes or kilobytes as long as it is correct. Having zero bytes downloaded and displayed as 1 KB scares me. The size must be counted in bytes internally. Whether it is displayed in bytes or kilobytes, that's a decision for managers. :-) > > This is wrong, too. You would get a response like 375 KB of 375 KB, which > > may be wrong if the real size is unknown and an error happens.. > > 375 KB of 0 KB is much more informative, IMHO. We simply do not know the real > > size if the server does provide it for us, thus we should not claim to know it. > > OK, I see what you mean, but consider the case that no error occured. For those > cases you do want "375 KB or 375 KB", instead of the nonsense value "375 KB of 0 > KB". Yes, but how do you know that no error occured ? You don't, at least with the current code. What about a compromise ? During a download 375 KB of ???? KB is displayed. If we could keep this after the download is completed everybody could be happy. You simply should not claim that the real size is known if it is not. Another suggestion : Once the size is counted in bytes, a failure status should be introducded. Instead of "Finished" something like "Incomplete" should be displayed in case of an error.
Comment on attachment 170780 [details] [diff] [review] Patch for two files. ok, I think I'm convinced that the exthandler code and parts of the download manager code are correct. I do think we want to keep these lines: - // Files less than 1Kb shouldn't show up as 0Kb. - if (mMaxBytes==0) - mMaxBytes = 1; Can you make a new patch with these lines readded?
Attachment #170780 - Flags: review?(cbiesinger) → review-
note that I agree with neil about the expected displayed value... I think this may be what is shown with this patch, is that correct?
The problem with that is we can't differentiate between very small files (1-512 bytes) and files of unknown size.
Attachment #170780 - Attachment is obsolete: true
Sorry, I forgot to include this text. It brings back the old behaviour of showing files in size 1-511 as 1 KB. I guess this is what everybody including me wants. What's new is the fact that 0 will be displayed as 0. Another improvement is the new termination status "Incomplete". It is shown whenever something is wrong with the file size. Of course on transmissions with an unknown size "Finish" is always displayed.
Attachment #171029 - Flags: review?(cbiesinger)
sorry for the delay, I'll try to review your patch tomorrow - real life is keeping me busy :-/
well that didn't work out, I hope I can find some time tuesday or wednesday
Comment on attachment 171029 [details] [diff] [review] Rewritten and extended, small files are handled like before. ok, nice that we now have an "Incomplete" message. I'd have kinda preferred it as a separate patch, but ok... + mCurrBytes = aCurTotalProgress; + mMaxBytes = aMaxTotalProgress; did you verify that the UI still shows correct values? + PRUint64 compare; + compare= LL_MAXUINT; + if ( LL_EQ( mMaxBytes, compare) ) + mDownloadState = FINISHED; can you change it to this: PRUint64 maxuint = LL_MAXUINT; if (LL_EQ(mMaxBytes, maxuint)) ... (you are avoiding the LL_MAXUINT in the LL_EQ to avoid a MSVC compiler bug, right?) in theory you can use the status argument to this function to determine successfulness. in practice only one of the save codepaths use this function to report errors... + if ( ! LL_IS_ZERO( mCurrBytes) && LL_CMP(mCurrBytes, <, compare) ) please follow the style of the file... that is, remove the spaces after ( and before ), and after ! I think why not use LL_NE here? hm... in fact, what's the purpose of these lines? + // XXX remove conversion if caller will handle size in bytes please note bug 273971 in this comment nsDownloadManager.h eh? why this change? hm, this patch won't apply (the files here are not all in the same directory)... how did you generate it?
Attachment #171029 - Flags: review?(cbiesinger) → review-
Changed a few variables to 64 bits. ( Sorry for the long delay )
Attachment #171029 - Attachment is obsolete: true
Attachment #176634 - Flags: review?(cbiesinger)
Comment on attachment 176634 [details] [diff] [review] Made more 64 bit clean, obeyed style (hopefully) xpfe/components/download-manager/src/nsDownloadManager.cpp + if (LL_EQ( mMaxBytes, compare)) don't use a space after the ( + LL_UI2L( compare, 1024); and here + // XXX remove conversion if caller will handle size in bytes should probably be "when", not "if" xpfe/components/download-manager/src/nsDownloadManager.h + mCurrBytes(aCurr ), + mMaxBytes(aMax ) remove the space before )
Attachment #176634 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #176634 - Flags: review?(cbiesinger)
Attachment #176634 - Flags: review+
(and sorry for the delay in reviewing :( )
Comment on attachment 176634 [details] [diff] [review] Made more 64 bit clean, obeyed style (hopefully) >- nsAutoString currBytes; currBytes.AppendInt(transferInfo.mCurrBytes); >- nsAutoString maxBytes; maxBytes.AppendInt(transferInfo.mMaxBytes); >+ PRFloat64 tmp_float; >+ LL_L2F(tmp_float, transferInfo.mCurrBytes); >+ nsAutoString currBytes; currBytes.AppendInt((PRUint32)(tmp_float/1024.0+0.5)); >+ nsAutoString maxBytes; While you're here can you complete the fix for the lazy coding style? i.e. nsAutoString currBytes, maxBytes; currBytes.AppendInt(...);
Attachment #176634 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Comment on attachment 176634 [details] [diff] [review] Made more 64 bit clean, obeyed style (hopefully) >- if (LL_CMP(delta, <, INTERVAL) && aMaxTotalProgress != -1 && aCurTotalProgress < aMaxTotalProgress) >+ if (LL_CMP(delta, <, INTERVAL)) So we're relying on the state change to handle the update when the current progress reaches the total progress? Presumably these fixes only apply to the download manager? Is there a bug for the progress dialog?
Removed even more spaces. Made one comparison 64 bit clean. Changed type of comparison to unsigned.
Attachment #176634 - Attachment is obsolete: true
Attachment #177328 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #177328 - Flags: review?(cbiesinger)
(In reply to comment #64) > (From update of attachment 176634 [details] [diff] [review] [edit]) > >- if (LL_CMP(delta, <, INTERVAL) && aMaxTotalProgress != -1 && aCurTotalProgress < aMaxTotalProgress) > >+ if (LL_CMP(delta, <, INTERVAL)) > So we're relying on the state change to handle the update when the current > progress reaches the total progress? AssertProgressInfoFor is called from DownloadEnded and from the destructor. > Presumably these fixes only apply to the download manager? Is there a bug for > the progress dialog? I've found three bugs : 87249, 91232, 279465. It looks like the Windows API discards rapid changes of gui elements. Mostly Linux and Mac machines seam to be affected.
Comment on attachment 177328 [details] [diff] [review] Checked in after review/superreview. >- mPercentComplete = 100; This line appears to have been deleted in error. You probably need to move it to where you set the state to FINISHED i.e. + if (LL_EQ(mMaxBytes, compare)) { + mDownloadState = FINISHED; + mPercentComplete = 100; + } + else You can either make this change, in which case my sr will stand, or you can re-request sr without the change, if you can explain why.
Attachment #177328 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
(In reply to comment #67) > (From update of attachment 177328 [details] [diff] [review] [edit]) > >- mPercentComplete = 100; > This line appears to have been deleted in error. No! mPercentComplete does have a defined value based on current/max. Have a look at bugs 236693 and 237623. Your assumption is wrong that a download always completes correctly. It fails way too often in real life and we should not pretend everything is o.k. in cases it is not.
Comment on attachment 177328 [details] [diff] [review] Checked in after review/superreview. re-requesting sr as requested (see comment 68)
Attachment #177328 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #177328 - Flags: superreview+
Attachment #177328 - Flags: review?(cbiesinger)
Attachment #177328 - Flags: review+
Comment on attachment 177328 [details] [diff] [review] Checked in after review/superreview. FINISHED = 100%
Attachment #177328 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview-
*** Bug 316585 has been marked as a duplicate of this bug. ***
Has Attachment 177328 [details] [diff] been checked in? It is marked superreview- in Flags and marked in comment 70: (From update of attachment 177328 [details] [diff] [review] [edit]) FINISHED = 100% maybe fixed by patch Attachment 202490 [details] [diff] [edit] for Bug 273971 nsIDownload should use bytes rather than kbytes + // Set file size at the end of a tranfer (for unknown transfer amounts) + if (mMaxBytes == -1) + mMaxBytes = mCurrBytes; +
Comment on attachment 177328 [details] [diff] [review] Checked in after review/superreview. Obsoleting due to bitrot.
Attachment #177328 - Attachment is obsolete: true
Flags: blocking-seamonkey1.1a?
*** Bug 343854 has been marked as a duplicate of this bug. ***
Assignee: bross2 → download-manager
QA Contact: chrispetersen
This is only polish, and though it would probably be nice to have, it's not blocking a release.
Flags: blocking-seamonkey1.1a? → blocking-seamonkey1.1a-
i had one of the dups, but agree with robert: This is not a blocking feature, its just nasty ;-)
(In reply to comment #48) >(In reply to comment #47) >>(From update of attachment 170780 [details] [diff] [review]) >>nsExternalHelperAppService.cpp >>- mWebProgressListener->OnProgressChange(nsnull, nsnull, mContentLength, >>mContentLength, mContentLength, mContentLength); >>+ mWebProgressListener->OnProgressChange(nsnull, nsnull, mProgress, >>mContentLength, mProgress, mContentLength); >>why not pass mProgress for all values? >This is wrong, too. You would get a response like 375 KB of 375 KB, which >may be wrong if the real size is unknown and an error happens.. But this code isn't executed in the cancel/error case (the file now uses the 64-bit versions but I'm talking about the call in ExecuteDestiredAction).
I am not sure if this is actually the same bug, but rather than filing the 100th dupe, I thought I add a comment here first. After downloading http://www.homecinemachoice.com/cgi-bin/outputpdf.php?file=WP/020/019_WP_020.pdf the file size in the Transferred column of the download manager is shown as "18014398509481984KB of 18014398509481984KB", although the file is really just 135KB in size. Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.1) Gecko/20061223 SeaMonkey/1.1
(In reply to comment #78) http://www.homecinemachoice.com/cgi-bin/outputpdf.php?file=WP/020/019_WP_020.pdf > the file size in the Transferred column of the download manager is shown as > "18014398509481984KB of 18014398509481984KB", Saving with right-click "Save as" the size is displayed correctly as 135kb, saving with left-click I'm seeing the big number above. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.2pre) Gecko/20070103 SeaMonkey/1.1
I'm seeing with a current SM trunk build Bug 360622. Try to save link target from https://wxx.example.com/. You will get no warning/error, the DL saving dialog pops shortly up and eventually there is no file saved but in Download Manager you will see "Finished" with 1kb of 1kb. I guess that is related.
I confirm these little bug. (xp sp2 with seamonkey 1.1.1): transféré 1801439.......984ko sur 1801439......ko and this for all the downloaded files. (maybe a wrong segmentation of memory )
Bug is still there: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3
This may be a different bug, but I think it's connected, if not directly related... If you go into offline mode, then "Save link target as..", there is no offline warning and Download manager shows "Finished - 1KB" when nothing at all is downloaded. (still looking to see if this bug has been reported already)
Works for me in the new download manager we're using in SeaMonkey 2.0 Beta 1 and later.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: