Closed Bug 228968 (NegativeDownload) Opened 21 years ago Closed 20 years ago

downloading a large file >2GB displays negative status values

Categories

(SeaMonkey :: Download & File Handling, defect, P1)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
seamonkey1.0alpha

People

(Reporter: spiros_ioannou, Assigned: Biesinger)

References

Details

(Whiteboard: see comment 53 before attaching more screenshots)

Attachments

(11 files, 3 obsolete files)

Trying to download Fedora Core 2 test 2 with negative values
66.23 KB, image/jpeg
Details
Problem also occurs under Firefox 0.9 (Windows)
15.67 KB, image/png
Details
Negative status values in Firefox 0.9.3
6.85 KB, image/png
Details
Problem also occurs in Linux, as seen here in Mandrake 10.1 Official.
14.95 KB, image/jpeg
Details
Also in 1.0 PR on linux
204.53 KB, image/jpeg
Details
all values negative (speed of download too) - Mozilla 1.7.5
71.56 KB, image/jpeg
Details
all values negative (speed of download too) - Mozilla 1.7.5
71.56 KB, image/jpeg
Details
Firefox 1.0 on Windows with a over-2Gb download....
45.90 KB, application/octet-stream
Details
Firefox v1.0.1 shows as negative, after 2GB download.
16.15 KB, image/jpeg
Details
final patch
64.55 KB, patch
Details | Diff | Splinter Review
negative values when downloading large (>2GB) file
14.19 KB, image/jpeg
Details
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:
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
Closed: 21 years ago
Resolution: --- → DUPLICATE
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*
*** Bug 230836 has been marked as a duplicate of this bug. ***
I can confirm that this happens in Mozilla 1.6 under Linux. Please update the OS field.
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
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. ***
*** Bug 243122 has been marked as a duplicate of this bug. ***
*** Bug 221359 has been marked as a duplicate of this bug. ***
*** Bug 245155 has been marked as a duplicate of this bug. ***
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
*** Bug 247921 has been marked as a duplicate of this bug. ***
*** Bug 251649 has been marked as a duplicate of this bug. ***
*** Bug 251828 has been marked as a duplicate of this bug. ***
*** Bug 252457 has been marked as a duplicate of this bug. ***
*** Bug 252872 has been marked as a duplicate of this bug. ***
*** Bug 252912 has been marked as a duplicate of this bug. ***
*** Bug 254643 has been marked as a duplicate of this bug. ***
*** Bug 253956 has been marked as a duplicate of this bug. ***
*** Bug 255005 has been marked as a duplicate of this bug. ***
Notice that the dialog reports a file size of ~74Mb while it should be ~4Gb. All the statistics are broken too.
*** Bug 257213 has been marked as a duplicate of this bug. ***
*** Bug 257266 has been marked as a duplicate of this bug. ***
I saw this today too, while downloading the World of Warcraft Stress Test beta from Fileplanet. File is 2,370,316,457 bytes.
*** Bug 257829 has been marked as a duplicate of this bug. ***
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
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. ***
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).
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.
*** Bug 265044 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 266861 has been marked as a duplicate of this bug. ***
*** Bug 266996 has been marked as a duplicate of this bug. ***
*** Bug 267465 has been marked as a duplicate of this bug. ***
*** Bug 267610 has been marked as a duplicate of this bug. ***
*** Bug 267869 has been marked as a duplicate of this bug. ***
(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.
*** Bug 268155 has been marked as a duplicate of this bug. ***
Depends on: 264599
Target Milestone: mozilla1.9alpha → mozilla1.8alpha6
Just had this grabbing a 2.4gb DVD image (again, Fedora)
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).
*** Bug 268679 has been marked as a duplicate of this bug. ***
*** Bug 268741 has been marked as a duplicate of this bug. ***
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
*** Bug 269531 has been marked as a duplicate of this bug. ***
*** Bug 269555 has been marked as a duplicate of this bug. ***
*** Bug 270397 has been marked as a duplicate of this bug. ***
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
*** Bug 272089 has been marked as a duplicate of this bug. ***
*** Bug 272315 has been marked as a duplicate of this bug. ***
*** Bug 272443 has been marked as a duplicate of this bug. ***
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...
*** Bug 274765 has been marked as a duplicate of this bug. ***
*** Bug 274978 has been marked as a duplicate of this bug. ***
*** Bug 276058 has been marked as a duplicate of this bug. ***
*** Bug 277637 has been marked as a duplicate of this bug. ***
*** Bug 277668 has been marked as a duplicate of this bug. ***
*** Bug 277752 has been marked as a duplicate of this bug. ***
*** 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 .
*** 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. ***
*** Bug 279706 has been marked as a duplicate of this bug. ***
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.
*** Bug 279995 has been marked as a duplicate of this bug. ***
*** Bug 280270 has been marked as a duplicate of this bug. ***
*** Bug 280314 has been marked as a duplicate of this bug. ***
*** Bug 280327 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 280757 has been marked as a duplicate of this bug. ***
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?
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.
*** Bug 281039 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 282210 has been marked as a duplicate of this bug. ***
I'd like it to be fixed by Firefox 1.1 => blocking aviary 1.1 ?
Flags: blocking-aviary1.1?
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. ***
*** Bug 283673 has been marked as a duplicate of this bug. ***
*** Bug 284459 has been marked as a duplicate of this bug. ***
Priority: -- → P1
Here is another proof that this bug exists in Firefox 1.0.1
(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).
*** Bug 286549 has been marked as a duplicate of this bug. ***
*** Bug 286585 has been marked as a duplicate of this bug. ***
*** Bug 286641 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — — Splinter Review
- 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)
*** Bug 287241 has been marked as a duplicate of this bug. ***
*** 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. ***
Target Milestone: mozilla1.8beta2 → ---
Target Milestone: --- → Seamonkey1.0alpha
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+
Attached patch additional patch for camino (obsolete) — — Splinter Review
this is an additional patch that's required so that camino still builds
Attachment #179516 - Flags: review?(bzbarsky)
Attachment #179516 - Flags: review?(bzbarsky) → review+
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.
Attached patch patch v2 (obsolete) — — Splinter Review
(includes the camino patch)
Attachment #178062 - Attachment is obsolete: true
Attachment #179516 - Attachment is obsolete: true
Attachment #179531 - Flags: superreview?(darin)
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
Attached patch final patch — — Splinter Review
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
Closed: 21 years ago → 20 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
*** Bug 289261 has been marked as a duplicate of this bug. ***
*** Bug 289942 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 263967 has been marked as a duplicate of this bug. ***
*** Bug 292873 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 294380 has been marked as a duplicate of this bug. ***
*** Bug 295216 has been marked as a duplicate of this bug. ***
*** Bug 295426 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
*** 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. ***
*** Bug 298776 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 302056 has been marked as a duplicate of this bug. ***
*** Bug 303302 has been marked as a duplicate of this bug. ***
*** Bug 303632 has been marked as a duplicate of this bug. ***
*** Bug 304161 has been marked as a duplicate of this bug. ***
*** Bug 304253 has been marked as a duplicate of this bug. ***
*** Bug 304289 has been marked as a duplicate of this bug. ***
*** 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. ***
*** Bug 307116 has been marked as a duplicate of this bug. ***
*** Bug 307125 has been marked as a duplicate of this bug. ***
*** 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. ***
*** 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. ***
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. ***
*** 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. ***
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. ***
*** 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. ***
*** Bug 331988 has been marked as a duplicate of this bug. ***
*** Bug 332871 has been marked as a duplicate of this bug. ***
*** Bug 338669 has been marked as a duplicate of this bug. ***
*** Bug 355854 has been marked as a duplicate of this bug. ***
Could this be same bug as bug #265441?
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: