Closed Bug 180672 Opened 22 years ago Closed 17 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: 17 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: