Closed Bug 180672 Opened 22 years ago Closed 18 years ago

Download manager somehow disabled completely, preventing file downloads entirely (source file could not be read) [Error Console: exception in contentAreaUtils.js]

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED INCOMPLETE

People

(Reporter: mozilla, Assigned: xanthian)

References

(
URL
)

Details

(Keywords: qawanted, Whiteboard: click URL above to fix)

Attachments

(11 files)

Bad compreg.dat
154.86 KB, text/plain
Details
Good compreg.dat
158.80 KB, text/plain
Details
example damaged compreg.dat file
142.80 KB, text/plain
Details
dir /s of the mozilla directory
29.98 KB, text/plain
Details
The corrupted compreg.dat
144.21 KB, application/octet-stream
Details
A bad compreg.dat when download manager (DM) wouldn't open
144.69 KB, text/dat
Details
Second bad conpreg.dat file, when bug reappeared on 2nd restart
168.53 KB, application/octet-stream
Details
Good compreg.dat where moz seems to be working fine!
165.19 KB, application/octet-stream
Details
Screenshot of failure
151.36 KB, image/png
Details
Bad compreg.dat
141.75 KB, application/octet-stream
Details
Files
28.03 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 I upgraded Mozilla 1.1b to 1.2b. At some point, downloads just stopped working. At first, I thought it was a specific file download issue, but I suspect that it has something to do with the download manager for the following reasons: A) File downloads were set to use the download manager. Even after changing the download setting in the options, I can't download any files (by directly clicking a file link OR right clicking and choosing "Save Target As...") B) When I click the Download Manager option in the tools menu, it doesn't even come up. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. As this doesn't involve a crash, I attempted a simple re-install by re-running the installer. However, nothing seems to have changed. Since a uninstall/reinstall may remove files you need to fix this problem, I haven't yet done that. Please contact me if I can send you any files to help track this down.
Does deleting compreg.dat and restarting help?
I had the same problem when I upgraded to 1.2b from 1.1 on my Windows ME box, and found that deleting compreg.dat DOES fix the problem. Maybe the installer program for 1.2 should delete this file automatically? Or maybe it should modify the offending region of the file that causes the download manager to go AWOL? I'm rather ignorant about these matters, so it's just an off the top of my head suggestion.
> Maybe the installer program for 1.2 should delete this file automatically? It does.
I still have this problem occasionaly in the 1.4 final release. Clicking on a download link won't work because nothing happens, Mozilla starts to do something but immediately stops. If you try to open Download Manager from the Tools menu, it does not appear. It seems to be completely disabled. I will try to delete compreg.dat next time it happens, but up to now I've been fixing it by reinstalling Mozilla every time. The bug status should be changed to NEW or ASSIGNED since people have verified this problem, even in later releases.
I am seeing this on 1.4 as well, and on NS 7.1
I am having the same problem. (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624) These are the symptoms I'm observing: 1. "Tools | Download Manager" does not open the download manager. The following JavaScript error is shown in the JavaScript Console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://communicator/content/tasksOverlay.js :: toDownloadManager :: line 51" data: no] 2. File attachments in our MS Exchange server's webmail interface are represented by a URL involving an ASP script. Downloading attachments via "Save Link Target As" fails, reporting that it can't read a file. (This turns out to be a zero length file in the temporary directory.) 3. Downloading files elsewhere, using "Save Link Target As", opens the "Save As" dialog. However, after clicking "Save", no progress dialog window opens. (The file isn't being downloaded.) Attempts to Fix: 1. Deleted downloads.rdf from profile; no change 2. Deleted components\compreg.dat; above symptoms disappear, downloading works again This would seem to explain why others report re-installing fixed the problem. Based on the symptoms I reported above, the following would appear to be duplicates of this bug: bug 189451, bug 193868, bug 202862, bug 203689, bug 203739, bug 204554, bug 208584, bug 208608, bug 209139, bug 210140, bug 210287, bug 210526, bug 210853, bug 214003, bug 215153, and bug 215198 (Bug 207375 might be a candidate for this list as well, but a different JavaScript error was reported.)
Bug 215339 and bug 215568 look like new dupes.
More possible dupes: bug 208275, bug 213698, bug 213954 Comment: Comparing a "good" compreg.dat vs. a "bad" compreg.dat, I noticed a number of missing entries when downloads stopped working, including the following: rel:nsDownloadProgressListener.js,1053598440000 rel:nsProgressDialog.js,1052948640000 {09cddbea-1dd2-11b2-aa15-c41ffea19d79},,text/javascript,,rel:nsDownloadProgressListener.js @mozilla.org/download-manager/listener;1,{09cddbea-1dd2-11b2-aa15-c41ffea19d79} @mozilla.org/progressdialog;1,{f5d248fd-024c-4f30-b208-f3003b85bc92} Attachments to follow. BTW this entry looks rather ominous: {141917dc-e1c3-11d3-ac71-00c04fa0d26b},@mozilla.org/timebomb;1,,Netscape TimeBomb,rel:appcomps.dll
Attached file Bad compreg.dat —
Attached file Good compreg.dat —
To compare the files, I first "sort" the contents and then use "diff" (or BeyondCompare).
This is still happening in Mozilla 1.4 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624). Deleting compreg.dat fixed it.
Potential dupes: bug 211119, although marked fixed, the bug may have been hidden by installing 1.5a and thereby removing compreg.dat bug 213137
Blocks: 213137
Too many bugs reported similar to this. UNCO -> NEW. However, looking at the time frame for the last known incidences of these disabled download manager bugs -- that is, anything that doesn't say WFM -- I'm strongly tempted to say this bug happened during a couple months, and may have been fixed by other actions. I've personally had no recent troubles with the download manager being totally disabled by accident. qawanted: (1) I suspect every single UNCO and NEW bug this bug "blocks" is actually a dupe of this bug. (2) There are several WFM comments after the timeline of initial bug reports.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Whiteboard: WFM?
I guess a lot of the blocked bugs could be closed because the problem is gone in newer versions.
Bug 257962, filed by me, which seems to be a duplicate of this one, shows * that the problem is still alive and well (at least for WinOS98SE) as of 2004090206 nightly, * that the bug symptoms are just slow to arise in Mozilla during use, * that the bug symptoms are made persistent once the bug cause is first triggered and the symptoms occur, by some munging of persistent file compreg.dat, * that removing compreg.dat (which then gets rebuilt cleanly with the next launch of Mozilla) "cures" the bug (really just hides its symptoms) for some unknown period (my experience was "5 days"), * that this current (180672) bug's OP is exactly correct: ** a re-install from the same install-exe without a prior de-install leaves the bug symptoms intact (compreg.dat isn't replaced), ** a de-install followed by a reinstall of the same nightly finds the bug symptoms gone (compreg.dat gets replaced with a clean copy), ** but finds the bug _cause_ surely still snuggly lodged wherever in the code image it lives. Notice that fixing the install to remove compreg.dat will fix a symptom, and prevent the munged compreq.dat from causing the bug _symptoms_ in subsequent Mozilla build installations of code images where the bug _cause_ may not even exist, but will have no effect on the bug _cause_, some misfeature that is munging compreg.dat. xanthian.
*** Bug 257962 has been marked as a duplicate of this bug. ***
The difference between the "good" and "bad" registry attachments (apart from the "good" one apparenlty having the "developer tools" added) is the complete lack of javascript components in the bad one. Here are a couple that might have bearing on this bug specifically: rel:nsDownloadProgressListener.js rel:nsHelperAppDlg.js rel:nsProgressDialog.js
The js component loader is registered slightly differently in the two compreg.dat attached here. In the good one the CLASSIDS entry is {6bd13476-1dd2-11b2-bbef-f0ccb5fa64b6},@mozilla.org/moz/jsloader;1,,JS component loader,gre:xpc3250.dll (that's all one line). The bad one is missing the contract ID (and description) {6bd13476-1dd2-11b2-bbef-f0ccb5fa64b6},,,,gre:xpc3250.dll Should this matter? I don't think the contract ID missing would affect the loading of this component. The component-loader category entry uses the contract ID. That's registered and from there we get to the classid and thus the library name. Still, how could it have registered without the contract ID or the description? That's been in the xpcmodule.cpp registration code since before this bug got filed, so it had to be in the version that created the "bad" registry attached to this bug.
How'd this end up on Blake? XPCOM wierdness --> dougt
Assignee: firefox → dougt
Component: Download Manager → XPCOM
Whiteboard: WFM?
No longer blocks: 189451
*** Bug 189451 has been marked as a duplicate of this bug. ***
No longer blocks: 204554
*** Bug 204554 has been marked as a duplicate of this bug. ***
No longer blocks: 209139
*** Bug 209139 has been marked as a duplicate of this bug. ***
No longer blocks: 203689
*** Bug 203689 has been marked as a duplicate of this bug. ***
No longer blocks: 215339
*** Bug 215339 has been marked as a duplicate of this bug. ***
No longer blocks: 210140
*** Bug 210140 has been marked as a duplicate of this bug. ***
No longer blocks: 210287
*** Bug 210287 has been marked as a duplicate of this bug. ***
No longer blocks: 210526
*** Bug 210526 has been marked as a duplicate of this bug. ***
No longer blocks: 210853
*** Bug 210853 has been marked as a duplicate of this bug. ***
No longer blocks: 214003
*** Bug 214003 has been marked as a duplicate of this bug. ***
No longer blocks: 215153
*** Bug 215153 has been marked as a duplicate of this bug. ***
wow. lots of dups. can anyone cc'ed on this bug reproduce this problem consistently?
(In reply to comment #31) > wow. lots of dups. Indeed, the bug is real enough, either has been in the code since 20021117, and thus is in ever stable build since then, or else has been recently reintroduced to the code to mimic the original bug. Based on the pattern of reporting, the former might be a better guess, it seems to have been reported across several major milestone releases. Presumably the bug is widely seen ... > can anyone cc'ed on this bug reproduce this > problem consistently? but probably it is not easily reproduced. I've been running a nightly build (2004090205) known to evoke the problem, and I've seen it re-occur exactly _twice_ in 24 days of steady 14 hour per day Mozilla use. Since the problem _symptoms_ are caused by corruption of persistent file compreg.dat, but the root bug, which creates the corruption, may have nothing to do with the problem symptoms as seen, only with the corruption, this problem isn't easily tested or reproduced. That's because as yet there isn't much clue what part of Mozilla, when exercised, evokes the bug and corrupts compreg.dat. Perhaps some of the source owners could give the rest of us a clue what parts of Mozilla, identified by functionality used, make writing to compreg.dat necessary, write to compreg.dat, or touch internal tables that get written to compreg.dat? That won't help if the problem is a wild pointer that happens to write those internal tables, but also happens to cause lots of other spooky bugs as well, but it will help if the problem is a bug with more predictable behavior, and give us functions on which to beat in hopes of exercising the buggy code. Eventually, such clues might find someone able to answer your question "yes" [as I was able to do a while back for another bug involving self-updating web pages that crashes Mozilla and your OS, normally takes a day to reproduce because it is a resource exhaustion problem, but can be reproduced in five minutes if you use a good guess at what evokes it and open lots of tabs to many different self-updating web pages at once]. By the way, I don't much understand the dev team bug classification terms, but is "new" appropriate for a bug that has been in the code for almost two years now? By now it should at least be "assigned", but it seems not to be.
I am using version 1.8 Alpha 4 Build ID: 2004091306. Since The download manager is disabled then I could not Download the latest nightly build.
I noticed that others only get the bug once in a while. In my case the download manager has never worked since I downloaded and built it. I don't know enough to know what code might be the problem but If someone could tell me what part of the code you might want to look at and which tools to use to get It. I will get the Information. Just tell me what to do.
I'd just like to report that bug 180672 is still alive and well on WinOS98SE as of the 2004093005 nightly build, and attach a second damaged compreg.dat file, in case commonalities with the existing attached one are interesting to bug chasers. Removing this compreg.dat file and relaunching Mozilla cleared up download problems. It is of interest that this time the corruption occurred relatively quickly, within less than 24 hours of updating to the new nightly build of Mozilla.
(In reply to comment #34) > I noticed that others only get the bug once in a while. In my case the download > manager has never worked since I downloaded and built it. I don't know enough > to know what code might be the problem but If someone could tell me what part of > the code you might want to look at and which tools to use to get It. I will get > the Information. Just tell me what to do. Based on private communication with Steve, his report should probably be a new bug, removing the compreg.dat file and relaunching Mozilla did _not_ clear up the problem for him, so probably this is a different bug with similar results. xanthian.
New corrupted compreg.dat is consistent: all the javascript components are missing. CC'ing shaver in case he has any insights What sites do you surf? Maybe we could attack it that way and find a common trigger. What plugins and versions do you have? Do you use Java? Kent, since you saw the problem so soon after installing the 9/30 build would it be possible to retrace your steps (using history) on that day and find a problem site? Since history only saves the last-visited date any site you've visited since won't show up on that day, but if you haven't had the problem since then we might be able to eliminate those pages as a cause anyway. You might want to copy your profile history.* somewhere to preserve the current evidence. The only actions that should trigger a write-out of compreg would be XPCOM registry changes. Normally I'd expect these only if you installed new software, or if something is touching component files making us update the filedates. Category manager changes also change the registry, but I've never seen a component do that other than at initial registration. Web pages can trigger an autoregister by invoking navigator.plugins.refresh() (related because plugins can be written as xpcom components). Normally nothing has changed, unless you've just installed their plugin, and nothing gets updated. about:plugins calls navigator.plugins.refresh() which is why that seems to fix this problem. At some point we've autoregistered and forgotten (or not found?) the js components, at a later point we can autoregister and magically find them again.
Flags: blocking-aviary1.0?
(In reply to comment #37) > New corrupted compreg.dat is consistent: all the > javascript components are missing. CC'ing shaver > in case he has any insights > What sites do you surf? Huge numbers too diverse to classify, but Yahoo News, Google Groups, and Mailgate.org receive the bulk of my attention. I happened, when the failure showed itself, to have followed a Yahoo News link to Space.com, but there's no telling how much earlier the damange to compreg.dat occurred. I've cut out and saved the portion of history.dat from the point where I downloaded the new build, to the point where I saw the failure. Probem is, I'm a pretty obsessed 'Web user, that less-than-a-day of Mozilla use porks up to 2.4 Megabytes of history.dat, probably a lot more than I can submit as a bugzilla attached file. I don't want to go trimming out parts _I_ don't think are pertinent that might be crucial evidence, to shrink the file size further. Anyone on the dev team want to receive a _really_ huge file in email, as a Yahoo mail attachment? > Maybe we could attack it that way and find a > common trigger. What plugins and versions do you > have? I don't know how to look. I know I use Acrobat Reader, Sun's Jave Runtime Environment, the RealPlayer, Quicktime, and Windows Media tools, as the most immediately obvious ones. > Do you use Java? Yes, but I don't recall using it in the timespan involved (which means nothing, I'm old and my memory is slipping badly). > Kent, since you saw the problem so soon after > installing the 9/30 build would it be possible to > retrace your steps (using history) on that day and > find a problem site? Since history only saves the > last-visited date any site you've visited since > won't show up on that day, but if you haven't had > the problem since then we might be able to > eliminate those pages as a cause anyway. You might > want to copy your profile history.* somewhere to > preserve the current evidence. It might be possible for _you_. I'm a shut-in depressive, and tasks longer than my brief attention span never get done. As above, I cut out the relevant portion of history.date and set it aside, I just need someone willing to weed through all that cruft, and find the guilty web page, if a web page is indeed the problem. One thing to the good, I don't use any Mozilla facility _except_ the browser, even though I take the default "complete" installation, so news and mail functionalities are _not_ involved. > The only actions that should trigger a write-out > of compreg would be XPCOM registry changes. > Normally I'd expect these only if you installed > new software, or if something is touching > component files making us update the filedates. Your explanation went over my head from this point down. > Category manager changes also change the registry, > but I've never seen a component do that other than > at initial registration. > Web pages can trigger an autoregister by invoking > navigator.plugins.refresh() (related because > plugins can be written as xpcom components). > Normally nothing has changed, unless you've just > installed their plugin, and nothing gets updated. > about:plugins calls navigator.plugins.refresh() > which is why that seems to fix this problem. At > some point we've autoregistered and forgotten (or > not found?) the js components, at a later point we > can autoregister and magically find them again. It might be pertinent, since you seem to be talking about Javascript problems, that I ran into a catastrophic Javascript failure (required a reboot to regain control) at a site fairly famous (with me) for crashing Mozilla and WinOS98SE together, in trying to follow this URL: http://newgrounds.com/audio/view.php?id=499097&sub=14610 Problem is, in a clean invocation of Mozilla after rebooting, the crash did not recur. Also, frankly, I don't remember if this was before or after the new install, but since the compreg.dat files persists across installs of Mozilla that don't nuke the data files, and I'm too scared of losing my bookmarks and history to say yes to my installer's "remove all associated data files", the damage to compreg.dat _may_ have preceded the new install (but not by much, I do _lots_ of downloads of computer theory *.pdf files, so there aren't any big windows where I'm not doing downloads at all). Once you successfully get to the page, clicking the "download" button near the "tbwaltz.*" button in the item at the top of the list evokes the error. The page, of course, isn't under my control, the owner has been informed of the problem, so it may have been fixed in the meanwhile. And, of course, this site may not be at all related to the download failure, but still...it beats wading through 2.4 megabytes of history.dat as a first option. xanthian. [Really now, does this two year old bug deserve to be still carried as NEW in bugzilla?]
In fact, on further reflection, the sequence of events for comment #38 was probably: Access above URLed site, http://newgrounds.com/audio/view.php?id=499097&sub=14610 Browser and OS crash (due to Javascript bug combined with existing heavy use == resource depletion, and lots of tabs open?). Reboot occurs via <CTRL><ALT><DELETE> on fifth try. Mozilla, relaunched, whines about being 4 weeks old. Sidetrack to uninstall four week old Mozilla, using the SmartLinks uninstaller, and _not_ chosing to remove associated data files, which may (or may not) mean the existing compreg.dat survived, possibly corrupt from the crash or earlier unrelated usage of Mozilla. Reinstall Mozilla from current (2004093005) nightly. Revisit site causing crash, hoping for a reproducible problem to report. No joy, but clicking the "download" button for the "tbwaltz.*" does evoke a Javascript bug, which may or may not be related to the corruption of compreg.dat in a way that nukes the Javascript stuff there. See other (space.com site) download failures, realize that download manager is dead again. Set aside compreg.dat, relaunch Mozilla, see downloads at space.com now working OK. Report bug still alive and well in Comment #35. FYI. xanthian.
Attachment #160777 - Attachment mime type: application/octet-stream → text/plain
In the most recent one damaged file, the JS component loader is listed correctly with a contract-id. Just noting that here for my reference.
Request for those seeing the crash: Please copy away the compreg.dat before restarting after you crash, as well as after you see that download manager doesn't work. I want to see if the corruption is happening due to a bogus autoreg on the restart, or is actually corrupted during the crash. Also, if you can send the ls -lR output (or equivalent on Windows -- file names, sizes, timestamps for all files recursively) for the profile and browser directories, that would help.
windows equiv is "dir /s"
seems like we're not getting any traction here. If we get somewhere in the next day or three, please renominate.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
(In reply to comment #43) > seems like we're not getting any traction here. If we get somewhere in the next > day or three, please renominate. I'm sure I'm missing something about the politics of Mozilla, but isn't the idea of a "blocking" bug: "this is so awful that if we let the software go out before we fix it, our reputation will be shot and the product crippled, so let's put a wall in the way and not proceed until it's FIXED", rather than "this is so awful that we really, really ought to see if anyone wants to look at it, before releasing our product broken anyway because no one can be bothered"? xanthian.
xanthian, that this bug ever had the blocking flag was probably wrong. We've shipped this problem for ages and we haven't gotten any further in our attepts to reliably reproduce or better understand the problem. If someone has the time to dig deeper into this and figure out what's going on enough to attempt a fix, I'd be happy to evaluate that fix for inclusion in upcoming releases.
Blocks: 227439
*** Bug 227439 has been marked as a duplicate of this bug. ***
Using Windows XP, I can trigger compreg.dat corruption nearly 100% of the time simply by going to http://www.ign.com, invoking Print Preview, changing print orientation from landscape to portrait (and back, if the first change didn't work), and then we crash. After restarting the browser (this is Seamonkey, not Firefox), compreg.dat needs to be deleted, or about:plugins needs to be visited before both the Download Manager and saving files to disk work. Shaver: as soon as I have ample time to do so, I'll go through your requests in comment 41, since I'm able to reproduce this problem so readily. Others: if you have time and inclination, please do follow my steps to crash and if you can, go through Mike's request in comment 41 and post your results here.
We should adopt the "Status Whiteboard" and "URL" from bug 227439 as known workarounds additionally to delete the compreg.dat file itself.
*** Bug 267008 has been marked as a duplicate of this bug. ***
*** Bug 271012 has been marked as a duplicate of this bug. ***
Summary: Download manager somehow disabled completely, preventing file downloads entirely → Download manager somehow disabled completely, preventing file downloads entirely (source file could not be read)
*** Bug 195083 has been marked as a duplicate of this bug. ***
*** Bug 273232 has been marked as a duplicate of this bug. ***
*** Bug 256365 has been marked as a duplicate of this bug. ***
*** Bug 273845 has been marked as a duplicate of this bug. ***
No longer blocks: 202862, 208608, 215198, 215568, 227439
Summary: Download manager somehow disabled completely, preventing file downloads entirely (source file could not be read) → Download manager somehow disabled completely, preventing file downloads entirely (source file could not be read) [JavaScript console: exception in contentAreaUtils.js]
I downloaded the nightly update about 7 hours ago: 20041217. I just tried to downloaed a file from: http://thesims2.ea.com/exchange/object_detail.php?&asset_id=62&loginRequireMsg=true login requiered. I discovered that the download manager Is disableed again. I can't display the download manager from the tools menu. It worked using the previous nightly build:
I just managed to make it happen on purpose by following the steps from comment #47 with a fairly recent build 20041215. Another consequence of the bug is that Proxy Auto Configuration doesn't work (I guess the proxy.pac is not being dowloaded for the same reason). Posting the corrupted compreg.dat. Dejan
Here's a new twist. I just upgraded from 1.8a4 to 1.8a6 (WinXP) and have symptoms exactly as described in the original submission. 1) Quit browser 2) Move compreg.dat to desktop 3) Lauch browser 4) Moz builds a fresh compreg.dat 5) Symptoms disappear, download work fine When I compare the compreg.dat on my desktop to the new one that Moz just created, they're *identical*. Well, this raises the obvious question: "If the compreg.dat is the same, then how did the symptoms disappear?". I'm not a moz developer so I can only guess... perhaps the problem isn't really *in* the compreg.dat, but somewhere else that gets touched anytime compreg.dat gets built from scratch.
*** Bug 278750 has been marked as a duplicate of this bug. ***
*** Bug 278319 has been marked as a duplicate of this bug. ***
*** Bug 280116 has been marked as a duplicate of this bug. ***
*** Bug 281477 has been marked as a duplicate of this bug. ***
*** Bug 283786 has been marked as a duplicate of this bug. ***
*** Bug 284116 has been marked as a duplicate of this bug. ***
*** Bug 284212 has been marked as a duplicate of this bug. ***
I cannot use mozilla untill the bug is fixed... I'll wait till the bug is fixed... I try to click on a download link, I get an error that says that it cannot save the file because it cannot be read. Reproducible: Always Steps to Reproduce: 1. I surf the net 2. I click on a download link 3. I try it again Actual Results: I get an error that says that it cannot save the file because it cannot be read. Expected Results: Download the file.
(In reply to comment #67) > I cannot use mozilla untill the bug is fixed... I'll wait till the bug is fixed... Michael: There is no need to copy your bug comment into this bug here again.
I am still utterly unable to find a cause for this, but I'll keep looking as I find time. Is anyone seeing this in Firefox? I haven't taken the time to scan all the dups to see, and it might help narrow the problem down. (Or, you know, it might not.)
Shaver: I've never seen this in Firefox, and I've triggered the same behavior that leads up to the failure (IE, crashes).
*** Bug 284960 has been marked as a duplicate of this bug. ***
This bug just happened to me. Here's the beta: * I downloaded the nightly from a night or two ago and started up moz to do some downloading of a couple things i needed * the download manager (DM) worked once or twice, then stopped working altogether (wouldn't open from Tools menu, nothing would download (even with right-click save-as) * i closed moz, removed compreg.dat (by renaming to the attachment, compreg.dat.bad), and i restarted moz. DM back. BUT....... * i did a couple downloads, including one from download.com * i closed moz, reopened moz - DM gone! * closed moz, removed compreg.dat (by renaming to compreg.dat.bad2), reopened moz - DM back! * downloaded one simple image, closed moz, reopened moz - DM stilll there! * closed moz, reopened moz, went to download.com, started download, canceled it * closed moz, reopred moz, DM still there! * Except for that first time, DM now seems to be working fine after a few reboots and downloads. * I'll attach both the bad compreg.dat files. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050306
2nd bad compreg.dat file (see previous post) * After removing the first conpreg.dat file, the download manager was restored. * I did a few downloads, closed and restarted moz, and the download manager was again gone. * So I closed moz, and this is the compreg.dat file from that state. * (When I subsequently removed this compreg.dat file, the download manager seems to be working fine now.)
Download manager seems to be working fine now, after steps of needing to delete two previous compreg.dat files (see last two posts).
when i crash with the crash in nsPluginInstanceOwner::Destroy stack (bug 285982), i am unable to download or save files afterwards. Deleting compreg.dat cures it. But the old/new compreg.dat files are identical. Another file, in my profile dir, is written to at the instant compreg.dat is recreated though: registry.dat So perhaps registry.dat is the corrupted file?
C:\Documents and Settings\me\Programdata\Mozilla\registry.dat
*** Bug 279849 has been marked as a duplicate of this bug. ***
*** Bug 287438 has been marked as a duplicate of this bug. ***
*** Bug 287078 has been marked as a duplicate of this bug. ***
(In reply to comment #75) > So perhaps registry.dat is the corrupted file? If you want to see what is in it, or edit it, there are tools to convert it to xml and xml back to registry.dat: http://www.alain.knaff.lu/~aknaff/howto/MozillaCustomization/cgi/readMoz.cgi
*** Bug 287908 has been marked as a duplicate of this bug. ***
*** Bug 287791 has been marked as a duplicate of this bug. ***
Blocks: 287791
#287078 is my download bug report and comments. It isn't the same as what's described here. Having reviewed the discussion of this bug, here are some comments that might be useful. What platforms do these problems occur on? Only Windows? There are conflicting reports about whether compreg.dat is the same or different when problems are found. The following was noted: ------- Additional Comment #75 From R.K.Aa. 2005-03-13 12:59 PST [reply] ------- when i crash with the crash in nsPluginInstanceOwner::Destroy stack (bug 285982), i am unable to download or save files afterwards. Deleting compreg.dat cures it. But the old/new compreg.dat files are identical. Another file, in my profile dir, is written to at the instant compreg.dat is recreated though: registry.dat So perhaps registry.dat is the corrupted file? End quote. See also comments #8, #17 and #18 which describe differences in compreg.dat including differences affecting Javascript. Is there any problem with the Javascript interpreter? If the problem is only on the Windows platform, has there been any Windows or IE update that affects Mozilla\Firefox registry settings, or Java/Javascript performance? What is the timebomb thing mentioned in comment 8? I've never seen the Download Manager fail to appear when I expect it to. I don't expect it to open when downloading a flash or shockwave display, but I do expect it to open for a download of a file to be saved. This is emphatically true of files of types not known to Mozilla's helper applications. Setting Debug or a viewer program to open a file is a workaround to get the file saved, but doing so shouldn't be necessary. Operations that rely on Javascript need to allow for slow server responses (including DNS servers) instead of timing out prematurely. I have seen Javascript error messages in temporary link failures. It may be that other pieces of code time out prematurely too. I sometimes get messages like "page not found" too soon after a click on a link to expect a response, and I reclick and then get the page. This suggests a timeout problem. Communication between file servers and Mozilla during downloads might have problems because of timing too.
I also meant to ask, does the disappearing download mgr bug occur in builds other than msvc builds, such as cygwin or mingw builds?
*** Bug 253211 has been marked as a duplicate of this bug. ***
*** Bug 262431 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+ Deleting the compreg.dat does NOT fix the problem for me!
(In reply to comment #87) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417 > Firefox/1.0+ > > Deleting the compreg.dat does NOT fix the problem for me! But it has worked for hundreds of people before, so your problem is a different problem.
Comment #83 quoting comment #75 and some other interesting observations: There are conflicting reports about whether compreg.dat is the same or different when problems are found. The following was noted: ------- Additional Comment #75 From R.K.Aa. 2005-03-13 12:59 PST [reply] ------- when i crash with the crash in nsPluginInstanceOwner::Destroy stack (bug 285982), i am unable to download or save files afterwards. Deleting compreg.dat cures it. But the old/new compreg.dat files are identical. Another file, in my profile dir, is written to at the instant compreg.dat is recreated though: registry.dat So perhaps registry.dat is the corrupted file? End quote. See also comments #8, #17 and #18 which describe differences in compreg.dat including differences affecting Javascript.
Blocks: majorbugs
No longer blocks: majorbugs
Flags: blocking-aviary1.1?
*** Bug 275998 has been marked as a duplicate of this bug. ***
This problem started occuring last week, for both Mozilla and Deep Park Alpha builds of firefox at the exact same time, deleting compreg.dat works but the problem comes back.
The recent problem is Bug 298478
(In reply to comment #92) > The recent problem is Bug 298478 Is that a different bug, or does that fix fix this one also? Anyone?
(In reply to comment #93) > (In reply to comment #92) > > The recent problem is Bug 298478 > > Is that a different bug, or does that fix fix this one also? Anyone? Please take the 10 seconds it takes to load both bugs and notice their 'Opened:' dates, and then make a logical determination that a bug from 2002 (this bug, bug 180672) is probably different from a bug filed in 2005 (bug 298478). In addition, please keep bugzilla comments/questions to useful ones. Thanks.
(In reply to comment #94) > (In reply to comment #93) > > (In reply to comment #92) > > > The recent problem is Bug 298478 > > > > Is that a different bug, or does that fix fix this one also? Anyone? > Please take the 10 seconds it takes to load both bugs and notice their 'Opened:' > dates, and then make a logical determination that a bug from 2002 (this bug, bug > 180672) is probably different from a bug filed in 2005 (bug 298478). In > addition, please keep bugzilla comments/questions to useful ones. Thanks. That's too harsh, and the prior query is a well justified one. The current bug doesn't have a solid way to reproduce it in place yet, but bug 298478, very similar, did while it was live. Those responsible for handling bug 180672 would be well advised to review the cause and cure for bug 298478, and check whether a similar "privileges" issue is what is the root cause of this current long standing bug. Also, "shooting the messenger" is a really terrible approach when almost all your bug reporting is being done by volunteers willing to run nightlies even though they _do not_ have the skills/interest/time/privileges to do the fixes or code research for the bugs reported. Of necessity, a great amount of the reportage from volunteers is going to be of class "static", and the folks down in the trenches need to practice the skills of patience needed to endure the heavy freight of dross for the occasional speck of precious metal, which, if commenting is disparaged, will be lost with the dross. xanthian, dross shoveler.
And by the way, am I the only one it gives screaming fits to see this bug still labeled "NEW" instead of "ASSIGNED", since 2002? xanthian.
i'm certainly not bothered by it, but you're welcome to work on this bug and post a patch at which point i'd be glad to see you mark it as assigned.
Assignee: dougt → xanthian
(In reply to comment #95) > (In reply to comment #94) > > (In reply to comment #93) > > > (In reply to comment #92) > > > > The recent problem is Bug 298478 > > > > > > Is that a different bug, or does that fix fix this one also? Anyone? > > Please take the 10 seconds it takes to load both bugs and notice > their 'Opened:' > > dates, and then make a logical determination that a bug from 2002 (this bug, > bug > > 180672) is probably different from a bug filed in 2005 (bug 298478). In > > addition, please keep bugzilla comments/questions to useful ones. Thanks. > > That's too harsh, and the prior query is a well justified one. The current > bug doesn't have a solid way to reproduce it in place yet, but bug 298478, > very similar, did while it was live. Those responsible for handling bug 180672 > would be well advised to review the cause and cure for bug 298478, and check > whether a similar "privileges" issue is what is the root cause of this current > long standing bug. > Thanks. > Also, "shooting the messenger" is a really terrible approach when almost all > your bug reporting is being done by volunteers willing to run nightlies even > though they _do not_ have the skills/interest/time/privileges to do the fixes > or code research for the bugs reported. NB: "volunteer" = "unpaid", yet providing some assistance and a bunch of their time.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 308080 has been marked as a duplicate of this bug. ***
*** Bug 309611 has been marked as a duplicate of this bug. ***
Regarding the preceding comment, "*** Bug 309611 has been marked as a duplicate of this bug. ***" From comment #94, "Please take the 10 seconds it takes to load both bugs and notice their 'Opened:' dates, and then make a logical determination that a bug from 2002 (this bug, bug 180672) is probably different from a bug filed in 2005 (bug 298478)." My bug #309611 has nothing to do with compreg.dat. It has to do with how files of different types are downloaded and what dialog boxes are displayed to give users some control over the downloading (filename, location, open/save). I decided to file bug #309611 because it continues to be an unrecognized, or un-isolated problem. This bug doesn't say that the download manager doesn't work. What it says is that some filetypes are handled with the appropriate dialog boxes and some aren't. This problem is not what bug #180672 is about.
My bad. My remarks are mistaken. The download bug I filed was #310468.
Even so, bug #309611 also pertains to incorrect handling of filetypes of downloads and failure to show the dialog boxes to give a user control of what's done with the downloaded file. It's an example of the data loss problem I mentioned in #310468.
*** Bug 311058 has been marked as a duplicate of this bug. ***
Bug has reappeard in Seamonky
The build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051005 SeaMonkey/1.1a refuses to save rar files from stream even if compreg.dat had been deleted before the suit started. This bug is dataloss bug, maybe money loss bug for someone! Some sites allow only one click to retreive file, the click takes money (virtual or not) from user's account. The bug is really critical.
Correct handling of more filetypes that people download to save on their own systems is what bug #309611 and #310468 are about. These problems probably don't have a hoot in hades to do with compreg.dat. Does compreg.dat have any information about filetypes known to Mozilla or registered on the system? I could list the bug numbers on which I've addressed this problem, and the latest is #310468. To be clear, we're talking about files to be downloaded (saved) on a local system, not downloads of POP mail, not web pages or elements thereof, etc. One obvious set of examples is copies of Mozilla/Seamonkey/Firefox/Thunderbird. Exe and zip files are generally handled right---though there have been bugs in the past. rar files were handled wrongly in a recent bug report, and marked wrongly as a dup of #180672. Mozilla doesn't handle downloads of bin files correctly all the time, which should go through the open/save and save-as dialog boxes as should rar files, etc. How does anyone figure this file mis-handling is caused by a buggy compreg.dat? It's caused by Mozilla not knowing what to do with some filetypes and automatically doing the wrong thing with them. Some files are for opening immediately, with no need to save them to disk (jpg, gif, txt, html, png). Receive them, display them, that's really all that needs to be done. Files for plugins fall into this category. Drop them into temp or the cache if desired, and open them without asking the user. Others, executables, are only for downloading for security reasons. Others, like zip files, are appropriate for asking about in the open/save dialog box. If "save" is selected, the program should bring up the save-as dialog. ANY filetype that's not known to Mozilla or the system registry should go through the open/save dialog box and, if desired, the save-as dialog box. Unknown files should not evoke a box to select a helper application, and then automatically be downloaded into temp whether or not a helper application is selected. They should go through the dialog boxes, and NOT be treated like files for plugins. I've written Commodore Basic programs to carry out comparable logic. The C++ code and Windows/Unix details are much more complicated, but why is the basic logic treated as such? Is there a flow chart anywhere showing the ifs and thens to be performed in downloading a file? Again, what does compreg.dat have to do with this logic, and why are these disparate downloading problems all being called dups of a compreg.dat bug?
I'd deleted the compreg.dat before Seamonkey has started, but the result is: C:\Documents and settings\...\Temp\d67d6.rar could not be saved, becase the source file could not be read. IE retrieves the file without problems.
Alexander, a way to save the rar file using Seamonkey is to add a new helper program to the helper programs listed in Preferences. If you have Unrar, that would be the ideal program to register there. Otherwise, you could set Notepad to open the rar file. After downloading, Notepad would open the file, and then you could exit Notepad without saving and then move the file from temp to where you really want it. You demonstrated that the problem you describe is a file-handling problem, not a compreg.dat problem.
*** Bug 321285 has been marked as a duplicate of this bug. ***
*** Bug 321285 has been marked as a duplicate of this bug. ***
Isn't anyone bothered about this. ? This bug is so infuriating. It's so easy to reproduce. How come seamonkey 1.0 got released with this bug ? It should be a blocker.
(In reply to comment #112) > Isn't anyone bothered about this. ? This bug is so infuriating. It's so easy to > reproduce. How come seamonkey 1.0 got released with this bug ? It should be a > blocker. No one can seem to figure out what the problem is. Can you provide some steps to reliably reproduce the problem? That would go a long way towards helping to find what the problem is so it can be fixed.
Attached image Screenshot of failure —
It's 100% reproduceable whenever i go to download any patch from kernel.org. So here are the steps. 1. Navigate to www.kernel.org 2. Click on the link '2.6.15.3' for eaxmple 3. You get the error (see attachment). It works if you right click and do 'Save Link as', so there is no problem on the server side. This happens with Firefox/SeaMonkey/Epiphany, etc.. so it's not a problem (as mentioned in this bug with compreg.dat - i.e. all of them can't be corrupted).
(In reply to comment #114) > It's 100% reproduceable whenever i go to download any patch from kernel.org. It`s not reproduceable (for me) because downloading this file worksforme with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ID:2006011112
Well, i see what Mitch means, but i really suspect this is another bug (with the same symptoms). Clicking that link does not completely disable the Download Manager or prevent other downloads, which would be the case if the kernel.org download bug would be this bug here.
So i logged bug 311058, but it was close as a dup of this, now you're saying this is not really the same bug (which i agree and is why i logged an independent bug). So how do we move this forward ? I logged the bug the time i noticed it happening so it's quite easy to figure out the regression since i do nearly weekly cvs builds. Shall i reopen my bug ? From comment #115 this doesn't appear to afflict Windoz ? Anyone else can confirm/deny ? For sure it fails on Solaris and Linux with cvs builds of FF/SM.
*** Bug 327096 has been marked as a duplicate of this bug. ***
Please see the discussion of bug #310468. There was an incorrect helper application setting perhaps made by an earlier version of mozilla. It might help to check on that problem and at least rule out that possibility as the source of this bug.
Ruled out. Remember my comment that this failure only occurs on some sites. So unless the 'helper' application failure is transient but consistent (contradiction) then it's not possible that this is at fault.
The issue may be the filetype to be downloaded, not the site. Until this and the helper application issue is looked into, it can't be ruled out.
Hello, are you not listening ? I ruled it out since i cleaned out all my helpers and it's still failing !! Next ?
Your previous comment didn't indicate that, Mitch.
i cant download anything
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 i have also problems download the patch for staroffice 8 from Sun: StarOffice 8 (Windows): Product Update 2 from http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/xprod-StarOffice&nav=pub-patches Direct Link 130MB: http://sunsolve.sun.com/pub-cgi/pdownload.pl?target=120187-02&method=h i get the error message from https://bugzilla.mozilla.org/attachment.cgi?id=211004&action=view i start a second download after error message and i have no problems, hmmmm
Attached file Bad compreg.dat —
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0
Attached file Files —
As a temporary workaround, why not call the JavaScript code that fixes the problem in the code that brings up the dialog box about not being able to read the file? That way, the dialog would appear only once, then the user could download files again.
It seems that problem is reproducing when newer Mozilla suite version being installed over old profile (with a lot of history, but upgrading browser by minor version, e.g. 1.7.<some last mozilla> -> Sea Monkey 1.0 -> Sea Monkey 1.0.1) The problem arose when mozilla was upgraded to 1.0 sea monkey and when sea monkey was upgraded.
Summary: Download manager somehow disabled completely, preventing file downloads entirely (source file could not be read) [JavaScript console: exception in contentAreaUtils.js] → Download manager somehow disabled completely, preventing file downloads entirely (source file could not be read) [Error Console: exception in contentAreaUtils.js]
(In reply to comment #129) > It seems that problem is reproducing when newer Mozilla suite version being > installed over old profile... I install a new version of SeaMonkey over an old one once a week or more, and that never seems to trigger the problem. Crashes are what seem to trigger the problem for me. If the idea in comment 128 sounds like it might work, and someone could point me to the code that would need to change, I'd be happy to give it a try and attach a patch if it works.
*** Bug 341258 has been marked as a duplicate of this bug. ***
I've been having this happen frequently when downloading a series of patches under Seamonkey 1.0.2 (often only minutes between occurances). This implies to me that it was some plugin that was invoked on one of those pages, which means I should be able to track down which one with a little experimentation.
QA Contact: chrispetersen → xpcom
I haven't been able to open THe DM since Seamonkey 1.0. I currently have Seamonkey 1.0.4. I can still download files and they complete but the DM does not appear. Right click save as fails. Deletion of compreg.dat has no effect.
Comradespike, please check your preferences/navigator/download settings to make sure that the download manager is set to open when downloading. If a version of seamonkey etc is sent with nothing set to open when downloading, that's what you will get. If you make that change and still don't see the DM, then there's a problem.
Comradespike, please check your preferences/navigator/download settings to make sure that the download manager is set to open when downloading. If a version of seamonkey etc is released with nothing set to open when downloading, that's what you will get (nothing). If you make that change and still don't see the DM, then there's a problem.
Sorry about the bug spam. The msg said my first send that I tried to stop would be overwritten by the second one. Incorrect. It just makes another post. See comment #83. I collected some info there that apparently hasn't been digested by those interested in this bug. compreg.dat may not be the problem. Registry.dat which is written at the same time could contain spurious info. The most important data it seems to hold is the location of the user's profiles.
(In reply to comment #135) > Comradespike, please check your preferences/navigator/download settings to make > sure that the download manager is set to open when downloading. If a version of > seamonkey etc is released with nothing set to open when downloading, that's > what you will get (nothing). If you make that change and still don't see the > DM, then there's a problem. > Thank you for the help but I double checked and it is set to come up but still refuses too and tools>download manager does nothing at all.
When I first started seeing this bug was when my download was 15% done. But now it has gotten worse, I dont even get to hit "OK" to start the download. I have deleted the compreg file. Doesnt work. I am running Windows 98. Firefox 1.5.0.6
When I first started seeing this bug was when my download was 15% done. But now it has gotten worse, I dont even get to hit "OK" to start the download. I have deleted the compreg file. Doesnt work. I am running Windows 98. Firefox 1.5.0.6
When I first started seeing this bug was when my download was 15% done. But now it has gotten worse, I dont even get to hit "OK" to start the download. I have deleted the compreg file. Doesnt work. I am running Windows 98. Firefox 1.5.0.6
By the way, same problem happend after upgrading to Sea Monkey 1.0.4 :( Solution described in https://bugzilla.mozilla.org/show_bug.cgi?id=341258 solved problem.
Which solution worked, the Javascript URL (Bug 341258, Comment 1) or reinstalling (Bug 341258, Comment 3)? By the way, the Javascript URL solution in Bug 341258 is also mentioned here, in the URL link at the top of the bug report.
Comment #1.
Happened in SeaMonkey 1.0.4 after a crash. I should note that there was no compreg.dat in the profile directory. Multiple restarts had no effect. Bringing up about:plugins appears to have fixed it, without having to reboot - this may be a clue.
compreg.dat is not in the profile, it is in the components/ subfolder in your program folder. At least for the "Download Manager not working after update" part we could do something about it. Maybe we should delete the file compreg.dat on update? Normally the core code should deal with an upgrade, but it seems this is not always the case.
Happened again after a system lockup (I have a bad video card). SeaMonkey 1.1a I verified: bringing up about:plugins fixes the problem. This _should_ be another clue - what happens in about:plugins that could fix this?
*** Bug 360020 has been marked as a duplicate of this bug. ***
*** Bug 364980 has been marked as a duplicate of this bug. ***
FYI: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 Have recently patched SeaMonkey. I still get this bug on occasion. Bringing up about:plugins fixes the problem. (In reply to comment #146) > Happened again after a system lockup (I have a bad video card). SeaMonkey 1.1a > > I verified: bringing up about:plugins fixes the problem. This _should_ be > another clue - what happens in about:plugins that could fix this?
Anyone have any idea what malefactor assigned to me a bug in a code base I have no possible way to work on as a maintainer? All that bit of mischief has accomplished is again to leave this major bug hanging unattended, now for over 4 years of disrepair. It seems the Mozilla project is in dire need of adult supervision, much like Google Groups' software maintenance is. FWIW xanthian.
timeless@bemail.org 2005-07-01 17:18:53 PDT AssignedTo dougt@meer.net xanthian@well.com
The download function of SeaMonkey now seems to work quite satisfactorily.
(In reply to comment #152) > The download function of SeaMonkey now seems to work quite satisfactorily. Not in all cases, it seems; reply 149 documents the bug still struggling to survive a mere seven weeks ago. xanthian.
(In reply to comment #150) > Anyone have any idea what malefactor assigned to > me a bug in a code base I have no possible way > to work on as a maintainer? That's what happens when you complain that a bug hasn't been assigned to / accepted by anyone (comment 96). It's basically a nice way of saying, "put up or shut up" (comment 97).
(In reply to comment #154) > (In reply to comment #150) >> Anyone have any idea what malefactor assigned to >> me a bug in a code base I have no possible way >> to work on as a maintainer? > That's what happens when you complain that a bug > hasn't been assigned to / accepted by anyone > (comment 96). It's basically a nice way of > saying, "put up or shut up" (comment 97). It's not a "nice way" at all, it is a childish, petulant response from some coward who both was incapable of accepting constructive criticism, and also unwilling to undertake fixing the bug. Major clue to such idiots: not everyone who chooses to be a beta tester due to having good bug reporting skills is in any way capable of _fixing_ those same bugs, and punishing your beta testers is behavior so far past stupid as to lack a suitable English word to describe it. Beta testers are unpaid labor, insulting us and trying to force work upon us which we are unable to do only damages the Mozilla project to no good effect. That is the kind of behavior expected onlu of those profoundly stupid or deeply mentally ill. It seems appropriate to re-publish anonymously some email I just received on this subject, documenting just how badly the Mozilla project shoots itself in the foot due to such childish, petulant, and incompetent administration. [begin quote] Your latest comments in this bug really struck a nerve with me. Back when I voted on this bug (since following some steps to compreg.dat fixed my browser), I never thought I would see e-mails continue to pour in to the different offices and homes I've lived over the years since it was opened. Out of frustration and curiosity I searched for unresolved (NEW->reopened) severe (blocker->major) bugs in Firefox and Core with at least 24 votes (this bug has 25). 33 of them are also no-priority (--), and almost all of them are unassigned (NEW). Most of the bugs also have many comments from impassioned users and developer-volunteers, which is not surprising given their votes. It gives me no satisfaction that dataloss and corruption are marked as low priority (priority --) according to the current setup. It also hasn't been marked as blocking, as another frustrated user (or perhaps it was yourself) points out. But this bug is in 'good company' (ie, other high-vote high-priority bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=193749 also do not have an assigned priority). Thanks for your comment #95 re: shooting the messenger and for your continued participation. A frustrated Mozilla volunteer user/debugger/patcher, [end quote] Since my correspondent mentioned the "shooting the messenger" paragraph in reply #95, is seems appropriate to repeat it here, in hopes some Mozilla project admin has the native intelligence to read it with understanding and to take remedial steps to get work done is a timely fashion, rather than letting major bugs sit unaddressed for many whole _years_. [begin quote] Also, "shooting the messenger" is a really terrible approach when almost all your bug reporting is being done by volunteers willing to run nightlies even though they _do not_ have the skills/interest/time/privileges to do the fixes or code research for the bugs reported. Of necessity, a great amount of the reportage from volunteers is going to be of class "static", and the folks down in the trenches need to practice the skills of patience needed to endure the heavy freight of dross for the occasional speck of precious metal, which, if commenting is disparaged, will be lost with the dross. [end quote] xanthian.
You seem to forget that almost all development in this project is also done by volunteers willing to work their asses off for the great community and get nothing in return, really. I propose this bug being resolved as WONTFIX, as apparently nobody is adding constructive comments and doing real work here anyways.
(In reply to comment #155) > bitch bitch bitch If this bug is so important to you, WhyTF haven't you found steps to reproduce it? Any idiot can use the browser and file bugs when they run into a problem, but a *useful* tester is someone who will actually take the time to figure out how to reproduce a problem. Based on the bugs you've filed, you're probably not one of the useful ones (I mean, bug 374746 is just a shining example of a great bug report</sarcasm>). If you're wondering why I'm pissed off, you try spending a few hours voluntarily cleaning the graffiti from a building (bug 242621), then have somebody complain that you didn't clean the next one over too (this bug). People like you make contributing *so* rewarding!
Re: comments 156 and 157. [Two more feeble minded individuals chime in for whom the fruitlessness of shooting the messenger is apparently beyond their limited understanding of human interactions.] I have no obligation whatever to BE a beta tester. As a beta tester, my obligation BEGINS and ENDS with my initial report of a bug. To think or contend otherwise is manifest idiocy: I'm as much a "volunteer" as any software maintainer is, and under no more obligation to lift a finger to help than those faux software maintainers whining because they cannot take honest criticism of this bug's grotesque lack of progress. [Nor is this bug the most egregious instance of hideously bad Mozilla software maintenance management. Critical data loss bug 63292 is still "NEW" after six years and several months. Is there really no one in all the Mozilla software maintainer cadre who knows how to write a "two-phase commit" functionality for history files? What do they teach in computer science curricula today, anyway, advanced basket weaving?] Making a bug reproducable may well require understanding the code to quite some level of depth, and instrumentation of the code to detect the genesis of the symptoms seen in behavior unseen, things which I as a beta tester might not in general know how to do, and certainly have not contracted to do. Deciding not to fix bugs using the excuse that the _beta testers_ haven't made those bugs reproducable would get you fired from any software maintenance job I've ever held or seen. [People with that mindset mostly get jobs working for Microsoft, instead of for employers with some grasp of corporate responsibility for producing functional software.] In the case of this bug, which has been repeatedly reported over several years, _none_ of the reporters seem to have found a way to reproduce the bug reliably, a strong clue that the base cause of the bug is far from the symptoms it produces, probably several steps of code or data corrupting causality away. I know _how_, in general, to fix bugs like that, and have done so hundreds of times over a 46 year programming career, but I have no intention doing so for Mozilla. Browsers are not any part of my programming field of interest (AI heuristics for computationally hard problems), so I stick to the contributions I can make, initial bug reports. To see bugs classified as "major" go unattended for many years, I'm sure, demotivates MOST beta testers sooner or later from reporting bugs _at all_. Just out of stubbornness, I've kept at that unthanked chore for over six years now. Your explanations of how this result (of demotivating beta reporters by failing to attend to their bug reports in a timely manner) (which by your comments criticizing beta testers you reinforce and prolong) helps the Mozilla project will, I'm sure, be intriguingly mendacious and inventive, shining a bright light on your particular brands of mental incapacity. As for marking a major functionality loss bug WONTFIX because the current cadre of Mozilla software maintainers can't be bothered to work the bug? That suggestion, and the person suggesting it, are both beneath contempt. Verbum sat sapienti. xanthian.
I'm not so sure about WONTFIX, but without steps to reproduce, this bug is INCOMPLETE.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INCOMPLETE
> As a beta tester, my obligation BEGINS and ENDS with > my initial report of a bug. And then to *shut the ____ up* so that somebody reading the bug doesn't have to read long tirades by self-important whiners who add no useful information. > ... I'm sure, demotivates MOST beta testers > sooner or later from reporting bugs _at all_. Don't worry. If you succeed at demotivating developers, there won't be any software to find bugs in.
Status: RESOLVED → VERIFIED
conclusion: Dear bug reporters, wo do not accept simple bug reports without steps to reproduce. Do not annoy the holy developers except you can deliver a first class bug report. In that sense we are not interested in feedback from the community (or the users as a whole?)</sarcasm>
Developers cannot fix bugs they cannot reproduce. Even if a developer stumbles on a way to reproduce what they think is the problem, it's entirely likely that it's a different issue and a fix to what they're seeing might not fix the issue for the original reporter. I've come across two such scenarios recently. INCOMPLETE doesn't mean "we don't care" it means "we can't do anything about it at this point." The intention is bugs that don't have enough information for people to work with are marked as INCOMPLETE until the reporter has more information, at which time it should be reopened, if it's short, or refiled with a clear comment#0. As it is, this bug has gotten quite long and unwieldy. There are many people talking about what appear to be several different issues here. People who are still seeing this bug should either reopen bugs they have already filed that are duped to this one, or file new bugs. It would also be incredibly helpful if people also sought support either before or after filing to help do some basic testing and triage and provide the bug with more clues for the devs to follow. - www.mozilla.com/support Many times support can at least help users find workarounds so they don't have to wait for a code fix to get on with using the products.
Confirming that this bug is real, and is still alive. A. Problem: Clicking on a download link (and then OK on "Enter filename" dlg) results in error message "... source file could not be read". B. Steps to reproduce: 1. Click on any download link on any site. C. Notes: -- File/link download works fine when using "Save link target as" (or Shift-Click). -- Bug appeared after "upgrading" from Mozilla Suite to Seamonkey 1.x -- Currently using SeaMonkey 1.1.2 (apparently not fixed in 1.1.3.) -- Not using "Download Manager" -- All file types not handled internally are set to "Save these files to disk". -- Suggested fixes (about:plugins, etc.) do not fix the problem.
This is a VERIFIED MAJOR BUG. Mozilla is unusable for any download where Shift-Click option is unavailable (eg: JS driven buttons), which means VERY OFTEN. Plus, many links have redirects so even when a download works with Shift-Click, the filename will be the name of the redirect (such as "download.php"), instead of the target file name. Please re-verify and change the status of this bug.
(In reply to comment #164) > This is a VERIFIED MAJOR BUG. > > Mozilla is unusable for any download where Shift-Click option is unavailable > (eg: JS driven buttons), which means VERY OFTEN. > > Plus, many links have redirects so even when a download works with Shift-Click, > the filename will be the name of the redirect (such as "download.php"), instead > of the target file name. > > Please re-verify and change the status of this bug. What you are describing sounds like a different bug. Please file a new one.
This bug has reappeared on SeaMonkey 1.1.11 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 ********************** unable to download images or video files download manager opens but nothing saves there are no options under tools/download manager ************************* XP SP2 Installed plug-ins Find more information about browser plug-ins at mozilla.org. Help for installing plug-ins is available from plugindoc.mozdev.org. Mozilla Default Plug-in File name: npnul32.dll Default Plug-in MIME Type Description Suffixes Enabled * Mozilla Default Plug-in * Yes RealJukebox NS Plugin File name: nprjplug.dll RealJukebox Netscape Plugin MIME Type Description Suffixes Enabled none RealJukebox NS Plugin File none Yes RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit) File name: nppl3260.dll RealPlayer(tm) LiveConnect-Enabled Plug-In MIME Type Description Suffixes Enabled audio/x-pn-realaudio-plugin RealPlayer(tm) as Plug-in rpm Yes RealPlayer Version Plugin File name: nprpjplug.dll 6.0.12.46 MIME Type Description Suffixes Enabled application/vnd.rn-realplayer-javascript RealPlayer Version Plugin rpj Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin7.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled image/jp2 JPEG2000 image jp2 Yes image/jpeg2000 JPEG2000 image jp2 Yes image/jpeg2000-image JPEG2000 image jp2 Yes image/x-jpeg2000-image JPEG2000 image jp2 Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin6.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled video/x-m4v Video (protected) m4v Yes image/x-macpaint MacPaint image pntg,pnt,mac Yes image/pict PICT image pict,pic,pct Yes image/x-pict PICT image pict,pic,pct Yes image/png PNG image png Yes image/x-png PNG image png Yes image/x-quicktime QuickTime image qtif,qti Yes image/x-sgi SGI image sgi,rgb Yes image/x-targa TGA image targa,tga Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin5.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled audio/3gpp 3GPP media 3gp,3gpp Yes video/3gpp2 3GPP2 media 3g2,3gp2 Yes audio/3gpp2 3GPP2 media 3g2,3gp2 Yes video/sd-video SD video sdv Yes application/x-mpeg AMC media amc Yes video/mp4 MPEG-4 media mp4 Yes audio/mp4 MPEG-4 media mp4 Yes audio/x-m4a AAC audio m4a Yes audio/x-m4p AAC audio (protected) m4p Yes audio/x-m4b AAC audio book m4b Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin4.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled video/mpeg MPEG media mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa Yes audio/mpeg MPEG audio mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a Yes audio/x-mpeg MPEG audio mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a Yes video/3gpp 3GPP media 3gp,3gpp Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin3.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled audio/x-gsm GSM audio gsm Yes audio/AMR AMR audio AMR Yes audio/aac AAC audio aac,adts Yes audio/x-aac AAC audio aac,adts Yes audio/x-caf CAF audio caf Yes audio/ac3 AC3 audio ac3 Yes audio/x-ac3 AC3 audio ac3 Yes video/x-mpeg MPEG media mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin2.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled audio/aiff AIFF audio aiff,aif,aifc,cdda Yes audio/x-aiff AIFF audio aiff,aif,aifc,cdda Yes audio/basic uLaw/AU audio au,snd,ulw Yes audio/mid MIDI mid,midi,smf,kar Yes audio/x-midi MIDI mid,midi,smf,kar Yes audio/midi MIDI mid,midi,smf,kar Yes audio/vnd.qcelp QUALCOMM PureVoice audio qcp Yes QuickTime Plug-in 7.5 (861) File name: npqtplugin.dll The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site. MIME Type Description Suffixes Enabled application/sdp SDP stream descriptor sdp Yes application/x-sdp SDP stream descriptor sdp Yes application/x-rtsp RTSP stream descriptor rtsp,rts Yes video/quicktime QuickTime Movie mov,qt,mqv Yes video/flc AutoDesk Animator (FLC) flc,fli,cel Yes audio/x-wav WAVE audio wav,bwf Yes audio/wav WAVE audio wav,bwf Yes Shockwave for Director File name: np32dsw.dll Adobe Shockwave for Director Netscape plug-in, version 11.0 MIME Type Description Suffixes Enabled application/x-director Shockwave Movie dir,dxr,dcr Yes Mozilla ActiveX control and plugin support File name: npmozax.dll Mozilla ActiveX control and plugin module MIME Type Description Suffixes Enabled application/x-oleobject ActiveX *.ocx Yes application/oleobject ActiveX *.ocx Yes DivX Player Netscape Plugin File name: npDivxPlayerPlugin.dll npdivxplayerplugin MIME Type Description Suffixes Enabled application/divxplayer-plugin npdivxplayerplugin scr Yes DivX® Web Player File name: npdivx32.dll DivX® Web Player MIME Type Description Suffixes Enabled video/divx DivX Video Files divx,div Yes SuperAdBlocker FireFox Plugin File name: npsabffx.dll FireFox Plugin MIME Type Description Suffixes Enabled application/x-sabffx sabffx scr Yes Adobe Acrobat File name: nppdf32.dll Adobe PDF Plug-In For Firefox and Netscape MIME Type Description Suffixes Enabled application/pdf Acrobat Portable Document Format pdf Yes application/vnd.adobe.x-mars Acrobat Portable XML Document Format mars Yes application/vnd.fdf Acrobat Forms Data Format fdf Yes application/vnd.adobe.xfdf XML Version of Acrobat Forms Data Format xfdf Yes application/vnd.adobe.xdp+xml Acrobat XML Data Package xdp Yes application/vnd.adobe.xfd+xml Adobe FormFlow99 Data File xfd Yes Shockwave Flash File name: NPSWF32.dll Shockwave Flash 9.0 r115 MIME Type Description Suffixes Enabled application/x-shockwave-flash Adobe Flash movie swf Yes application/futuresplash FutureSplash movie spl Yes DivX® Content Upload Plugin File name: npUpload.dll DivX® Content Upload Plugin MIME Type Description Suffixes Enabled application/x-divxcontentupload Yes Silverlight Plug-In File name: npctrl.1.0.30401.0.dll 1.0.30401.0 MIME Type Description Suffixes Enabled application/x-silverlight npctrl scr Yes MetaStream 3 Plugin File name: npViewpoint.dll MetaStream 3 Plugin r4 MIME Type Description Suffixes Enabled application/x-mtx MetaStream Plugin File mtx Yes Java(TM) Platform SE 6 U3 File name: npjava14.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-applet;version=1.4.2 Java Applet Yes application/x-java-bean;version=1.4.2 JavaBeans Yes application/x-java-applet;version=1.5 Java Applet Yes application/x-java-bean;version=1.5 JavaBeans Yes application/x-java-applet;version=1.6 Yes application/x-java-bean;version=1.6 Yes Java(TM) Platform SE 6 U3 File name: npjava32.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-applet;version=1.3 Java Applet Yes application/x-java-bean;version=1.3 JavaBeans Yes application/x-java-applet;version=1.2.2 Java Applet Yes application/x-java-bean;version=1.2.2 JavaBeans Yes application/x-java-applet;version=1.2.1 Java Applet Yes application/x-java-bean;version=1.2.1 JavaBeans Yes Java(TM) Platform SE 6 U3 File name: npoji610.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-vm Java Yes Java(TM) Platform SE 6 U3 File name: npjava11.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-applet;version=1.1.1 Java Applet Yes application/x-java-bean;version=1.1.1 JavaBeans Yes application/x-java-applet;version=1.1 Java Applet Yes application/x-java-bean;version=1.1 JavaBeans Yes application/x-java-applet Java Applet Yes application/x-java-bean JavaBeans Yes Java(TM) Platform SE 6 U3 File name: npjava12.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-applet;version=1.2 Java Applet Yes application/x-java-bean;version=1.2 JavaBeans Yes application/x-java-applet;version=1.1.3 Java Applet Yes application/x-java-bean;version=1.1.3 JavaBeans Yes application/x-java-applet;version=1.1.2 Java Applet Yes application/x-java-bean;version=1.1.2 JavaBeans Yes Java(TM) Platform SE 6 U3 File name: npjava13.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-applet;version=1.3.1 Java Applet Yes application/x-java-bean;version=1.3.1 JavaBeans Yes application/x-java-applet;version=1.4 Java Applet Yes application/x-java-bean;version=1.4 JavaBeans Yes application/x-java-applet;version=1.4.1 Java Applet Yes application/x-java-bean;version=1.4.1 JavaBeans Yes Java(TM) Platform SE 6 U3 File name: npjpi160_03.dll Java Plug-in 1.6.0_03 for Netscape Navigator (DLL Helper) MIME Type Description Suffixes Enabled application/x-java-applet;jpi-version=1.6.0_03 Java Applet Yes application/x-java-bean;jpi-version=1.6.0_03 JavaBeans Yes Windows Media Player Plug-in Dynamic Link Library File name: npdsplay.dll Npdsplay dll MIME Type Description Suffixes Enabled application/asx Media Files * Yes video/x-ms-asf-plugin Media Files * Yes application/x-mplayer2 Media Files * Yes video/x-ms-asf Media Files asf,asx,* Yes video/x-ms-wm Media Files wm,* Yes audio/x-ms-wma Media Files wma,* Yes audio/x-ms-wax Media Files wax,* Yes video/x-ms-wmv Media Files wmv,* Yes video/x-ms-wvx Media Files wvx,* Yes Microsoft® DRM File name: npdrmv2.dll DRM Netscape Network Object MIME Type Description Suffixes Enabled application/x-drm-v2 Network Interface Plugin nip Yes Microsoft® DRM File name: npwmsdrm.dll DRM Store Netscape Plugin MIME Type Description Suffixes Enabled application/x-drm Network Interface Plugin nip Yes
John, do you want your data opened with a plugin, or downloaded to a local file? Give me a link that you have a problem with, and I'll try downloading it with SM 1.1.11 for Linux.
With a clean profile I cannot download file from this link (and other files on this site): http://dox.bg/files/dw?a=1abb6d1a24 ff 50.1.0, other browsers like Midori can download it. But with Firefox I see the "source file could not be read" message. Can anybody look at this?
Alexander, whatever bug you are experiencing is not this very old closed bug. Please file a new bug report with as much detail as possible, including steps to reproduce, actual results, etc.
Flags: needinfo?(akostadinov)
@Benjamin, yep, I filed already bug 1326014. Would be good if some developer can reproduce before the file from the link disappears as I think issue might be site as well filename dependent. (FYI captcha requires only digits so don't be intimidated by Cyrillic characters on the site). Steps to reproduce is just go download the file.
Flags: needinfo?(akostadinov)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: