257962 - downloads silently fail to begin, none of dialog occurs

Status: RESOLVED DUPLICATE of bug 180672

(SeaMonkey :: Download & File Handling, defect)

Description

[Kent Paul Dolan]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040811
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040811

This looks like a recurrance of a year old bug.

In the 20040902 nightly build, right clicking a link and choosing "save link
target as" does nothing but clear the popup menu. No download dialogue occurs.
I reverted to the 20040811 nightly build to check that downloads that were
failing did work, so this bug is new since then. It isn't necessarily in the
Download Manager (bugs should be sorted by functionality, which the user
knows, not component, which the user has no particular reason to know), but
that's the only "component" with "download" in the name, so that's where it's
going.

The bug is easily replicated, Mozilla of that nightly build can't download the
next nightly build, a bit of a problem for folks who don't keep several backups,
making this a CRITICAL problem both in terms of lost major functionality, and
because it is likely to cut a cadre of beta testers out of the loop.


Reproducible: Always
Steps to Reproduce:
1. Attempt to download the latest Mozilla nightly build using the 20040902
nightly build, by opening the nightly builds page and right clicking on the
appropriate build.
2.
3.

Actual Results:  
Nothing happened.

Expected Results:  
A "save as" requestor should have appeared, the file should have downloaded, the
download manager window should have popped up to show progress.


This was experienced with a freshly downloaded nightly build, unmodified.

Comment 1

[Boris Zbarsky [:bzbarsky]]

What's the first nightly build showing this bug?

Comment 2

[Kent Paul Dolan]

If you're asking me, I don't know. The feature works in the 20040811 nightly,
fails in the 20040902 nightly, but I didn't install any of the builds in
between.

xanthian.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I guess the question was whether you have time to try some of the in-between
builds...

Comment 4

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040903
downloaded with a 20040830 nightly with left-click on a zipfile, save as...

left-click on URL: above, or right-click to open in new tab, produces a download
dialog:
Opening Mozilla-win32-installer.exe

The file .... is of type application/x-msdos-program
...
What should Mozilla do with this file?
[ ]  open it with ...
[x]  save it to disk
[ ]  Always perform this type of action ...

After confirming, the download starts.
If you checked [x] always perform.... you´ll never see that dialog again, even
when you selected wrongly, ( Open it with: Mozilla will give an endless loop)

You can check these settings in Preferences->Navigator->HelperApplications
Select the file type and click on Edit.

What are your settings in:
Preferences->Navigator->Downloads
[x]  open the download manager
[ ]  open a progress dialog
[ ]  don´t open anything

Comment 5

[Kent Paul Dolan]

> Comments From [e-mail]
> wfm Mozilla/5.0 (Windows; U; Win98; en-US;
> rv:1.8a3) Gecko/20040903

It works for me with the 20040811 build, too; the error report was
specific to the 20040902 nightly build.

> downloaded with a 20040830 nightly with left-click
> on a zipfile, save as...

Are you saying you tested with the 20040830 build,
or the 20040903 build, or what?

> left-click on URL: above, or right-click to open in
> new tab, produces a download dialog:

> Opening Mozilla-win32-installer.exe

Not for me.

> The file .... is of type application/x-msdos-program
> ....
> What should Mozilla do with this file?
> [ ]  open it with ...
> [x]  save it to disk
> [ ]  Always perform this type of action ...

> After confirming, the download starts.
> If you checked [x] always perform.... you¦ll never
> see that dialog again, even when you selected
> wrongly,

Nope, didn't touch it, and in any case, the
downloads were not executed, nor did the "save as"
dialog appear.

> ( Open it with: Mozilla will give an endless loop)

> You can check these settings in
> Preferences->Navigator->HelperApplications
> Select the file type and click on Edit.

Shows: Description: Application
       Extension:   exe
       When encountered: Save these files to disk

> What are your settings in:
> Preferences->Navigator->Downloads
> [x]  open the download manager
> [ ]  open a progress dialog
> [ ]  don¦t open anything
 
As you have shown.

Sigh. And of course when I uninstalled 20040811 and
reinstalled 20040902 just now to check those
settings, downloads _now_ work just fine, using the
same download of the install *.exe as before for
20040902 (since I'd saved it to disk).

Withdraw or invalidate this bug, whoever can,
apparently something hiccupped in my previous
installation of Mozilla 20040902, or my OS munched
the disk-resident executable code copy, or I left
my mind in my other suit, or something, and I
should have done one more round of uninstalls and
reinstalls and reboots and such before reporting
the bug.  Mea culpa.

xanthian.

May I mention my contempt for MS-Windows? Gak!
This kind of garbage doesn't happen under competent
OSs.

Comment 6

[Kent Paul Dolan]

Turned out I had sufficient privileges as the bug originator
to mark it INVALID myself.

Comment 7

[Kent Paul Dolan]

Okay, I'm turning this one back on, it happened
again with the reinstalled 20040902 nightly build,
too. This is going to be a bugger to isolate, it
took five days of Mozilla constant use (16 hours a
day every day; I'm obsessed with Usenet) to fail
again, though I haven't been doing downloads enough
in that interval to know just _when_ the fail state
was entered. At that rate, though, it would take a
month to isolate to a particular night's build by
binary search from 20040811 to 20040902, so I can't
do that, no one will care about the 20040902 nightly
by then and I might not have computer access that
long. I'm going to leave my setup broken for now so
that I don't destroy possible evidence.

I shut down Mozilla and rebooted WinOS98SE, and the
failure to download remained when I relaunched
Mozilla. I'm sure reinstalling Mozilla would give a
temporary respite, but I want not to do that in case
there is some evidence salvagable from the fail
state.

Is there anything in the persistent data that might
be of interest in figuring out what is happening,
that I could forward to someone? When this happens
twice in a row, it is just too unlikely that
WinOS98SE hit a spot in the code disk footprint
_again_ that exactly imitates the prior failure, so
now Mozilla is the prime suspect, and the prime
suspicion is that this is a self-inflicted wound,
though possibly dependent on some downloaded data
file to evoke it.

Notice that folks who run nightlies and replace them
every day or two might not notice this failure even
though it was present, since it isn't immediate, and
is probably dependent on some intermediate failure
possibly having a cause unrelated to downloading. I
ran the 20040811 nightly until 20040902, so I'm
fairly confident it was clean of the cause of this
failure, but I cannot say where in between the two
dates it might or might not first have occurred.

I'm looking for advice as to how to be useful in
isolating the problem, with the caveat that I don't
have the debugging tools developers take for
granted, though I can download such ones as work
in WinOS98 using wget(), I suppose.

xanthian.

To re-answer previous questions now that I am
looking at a "failing instance" of Mozilla 20040902
nightly, and not a "just cleanly installed"
instance, "Helper Applications" for
"application/x-msdos-program" is set to "save these
files to disk" (though downloads failed for a
"README" file with no tag and a *.tar.gz" file too,
not just for a *.exe file as was the focus of
discussion before) and "Downloads" is set to "Open
the download manager", both in
Edit=>Preferences=>Navigator.

Comment 8

[Hermann Schwab]

Do I understand correctly you are seeing this bug not only on .exe, but also
archives and textfiles, README? If that bug is happening again, can you just
save the website, File->Save Pages As->Webpage, HTML only. I´m not interested in
the content, just the fact if saving the website is possible, or not. If you see
the bug, is saving completely broken, or does it work on some other pages?
Do you have sufficient disk space? I don´t recall the exact behavior, or if it
changed lately, but files were not instantly saved in the location you
specified, but started saving in the temp file, or the cache, and were moved to
their location later on.

When the bug happens next, perhaps you can try a new profile, just for test?
Copy the URL, select Tools->Switch Profile, then in the upcoming Profile Manager
the button at the left, Manage Profiles, to create a profile. Create it, select
it, and start it. The browser does a restart, and when it comes up again, you
can copy the URL you wanted to the location bar. Does it work then?

There is another nasty behaviour of Mozilla regarding downloads: the download
manager data (history) is saved in downloads.rdf in your profile, and as this
file grows, and grows, you need more and more time until the download dialog
comes up. Deleting some entries using the download manager is very slow, if you
don´t need the info in that file it is best to delete the whole file manually,
or just copy it to some backup location. That must be done while Mozilla isn´t
running, an empty file will be recreated at next start.

Comment 9

[Kent Paul Dolan]

[Sorry if I'm too impatient and this appears twice, but an email response
doesn't seem to get inserted here.]

Hermann,


It was not possible to save an arbitrary web page when I tried that with
the currently failing 2004090206 nightly build.

When I created a new "testing" profile, (I had been "default user")
selected it, and clicked "use profile", nothing visible happened, in
particular, Mozilla did not restart itself, nor was I able to save a web
page. My list of bookmarks hadn't changed, so probably no useful change
to a different profile was accomplished.

When I exited Mozilla, relaunched it, I (for the first time ever) got
asked to choose a profile, chose "testing", Mozilla opened at a small
size, perhaps 500x700 pixels or so, I had no bookmarks but the built in
ones, I again attempted to save the same web page (some sales site for
a replacement bladder for a boxer's speed punching bag I'd been
viewing), saving was directed to the default location when the save as
requester came up, I changed to an empty directory, selected "save",
there was a short pause, the requestor closed, and the web page had
failed to save to disk. I'm convinced that I was now using a new
profile, and that it didn't change the symptoms.

I clean out the downloads page list by hand every time it gets to be a
windowful, so that's not the issue.

FYI

xanthian.

Comment 10

[Hermann Schwab]

Maybe a dupe of one of these:

Bug 227439	Unable to download files ("...could not be saved, because the source
file could not be read.")

see Bug 227439 comment 20 for workaround (delete compreg.dat)

Bug 180672  	Download manager somehow disabled completely, preventing file
downloads entirely

has a lot of unresolved dupes.

Comment 11

[Kent Paul Dolan]

Responding to comment 10:

The first referenced bug (227439) doesn't sound like
what I was seeing, no such dialog occurred. However,
in an offline interaction with Hermann Schwab, I
followed his suggestion to delete compreg.dat,
relaunch Mozilla, and retry saving.

Doing so makes it possible for Mozilla to
successfully save its own home page to my hard drive
with no other changes, and compreg.dat gets rebuilt
on the fly.

Of course, naively, I didn't back up compreg.dat,
failing version, so now I'm stuck waiting for the
failure to re-arise in a few days to get a copy of
compreg.dat that contains whatever brokenness causes
the error to arise and persist.

Sorry about that. Senility is winning the race,
hands down.

The second referenced bug (180672), however, sounds
like _exactly_ what I was seeing, right down to the
temporary bandaid that make its symptoms go away for
a while, making this bug a duplicate of 180672, so I
stuck a comment over there pointing at this bug and
trying to sidetrack some of the more muddle-headed
misunderstandings of useful directions to proceed in
that bug's comments.

xanthian.


*** This bug has been marked as a duplicate of 180672 ***

Comment 12

[Kent Paul Dolan]

Just a note that this bug is alive and well in the 2004112707 nightly build.

I saved a copy of the damaged compreg.dat.

If anyone wants to look at it, I can upload it to bugzilla.

I'm guessing though, that plenty of instances have been uploaded already.

xanthian.

Comment 13

[Hermann Schwab]

(In reply to comment #12)
> Just a note that this bug is alive and well in the 2004112707 nightly build.
> 
> I saved a copy of the damaged compreg.dat.
> 
> If anyone wants to look at it, I can upload it to bugzilla.

Please have a look at 
Bug 180672 Download manager somehow disabled completely, preventing file
downloads entirely (source file could not be read)

in Bug 180672 Comment #41 Mike Shaver  asks for some info