85115 - Downloads aren't saved to chosen destination folder

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Christopher Galey]

Downloads aren't saved to the chosen destination folder unless saved using
right-click & "Save Link As".  Left-clicking on a download link saves the file
with a random filename albeit with the correct extension in the \WINDOWS\TEMP
folder even though a download directory has been chosen.  This has been true of
all the builds I have used so this could have been submitted before but I
couldn't find it in the buglist.  I'm currently using the June 10th nightly. 
I'm running Windows 98 on a machine with an AMD K6-2 350mhz processor and 128MB RAM.

Comment 1

[Christopher Galey]

Attachment: Download dialog screenshot.

Comment 2

[timeless]

you didn't include a build id.

it's odd, because what you're seeing is us offering the run method which i can 
understand using temp. but then we shouldn't have asked for a location.

no matter, i think we've stopped offering run or something like that.

Comment 3

[Christopher Galey]

The build ID is 2001061008.

After I left-click a download link I get a box asking if I want to use the
default action for the file or use a different action with the file.

If I use the default, it downloads to \WINDOWS\TEMP with a strange filename and
launches.
If I choose to "Use a different action for this file" and select "Save this file
to disk" I can choose a directory to store it, but it still just saves
kslgiclx.exe to \WINDOWS\TEMP rather than saving it in the directory I chose.
It will successfully download to the chosen directory with the original filename
if I right-click a download link and chose "Save link as".

Comment 4

[sairuh (rarely reading bugmail)]

bill/pchen, could this be a manifestation of bug 79231 or bug 79503?

Comment 5

[Matthias Versen [:Matti]]

*** Bug 85732 has been marked as a duplicate of this bug. ***

Comment 6

[Matthias Versen [:Matti]]

confirming based on the dupe

Comment 7

[Keyser Sose]

*** Bug 87208 has been marked as a duplicate of this bug. ***

Comment 8

[Jim Wilson]

This is happening to me as well. AAMOF, the file downloaded doesn't even have
the same name as the source file did -- it appears to be just a random series of
letters/numbers (but with the correct extension). I'm using Win2K Professional
with SP1 and the "official" release version of 0.9.1.

Comment 9

[Keyser Sose]

*** Bug 84197 has been marked as a duplicate of this bug. ***

Comment 10

[Keyser Sose]

Changing info based on dupe.For me creating a new profile fixes this problem.

Comment 11

[Dave Booth]

Confirmed creating new profile makes the problem go away on Solaris8/SPARC build
2001071522

Comment 12

[Lythande]

See my comments on 55690

Comment 13

[Keyser Sose]

*** Bug 84855 has been marked as a duplicate of this bug. ***

Comment 14

[Steve Chapel]

How do I create a new profile? There doesn't seem to be any info on this topic
in the Help or in the Release Notes!

Comment 15

[Matthias Versen [:Matti]]

schapel ([e-mail]):
run "mozilla -profilemanager" 

Comment 16

[[e-mail]]

Creating a new profile isn't much of a fix, because I want to keep all my mail
and other settings from my old profile :-( So what's wrong with the old profile?

Comment 17

[timeless]

it's either prefs.js or localstore.rdf

Comment 18

[benc]

We need to isolate this. My guess is localstore.rdf is the place to start.

Comment 19

[benc]

*** Bug 87908 has been marked as a duplicate of this bug. ***

Comment 20

[Bill Law]

Is there still a bug here (I mean aside from the resemblence to 55690)?

I think there might have been a bug at some point where the file name that 
showed up in the progress dialog was that of the temporary file rather than 
that of the ultimate destination, but if so, that has been fixed.

If you choose to "open" using some application, then the progress dialog will 
have the name of the temporary destination file (because that's all we have).

Can I close this bug?

Comment 21

[Christopher Galey]

I still have the same bug as of build 2001012208.  I can only control the name
and destination of a download by right-clicking and choosing "Save As" or "Save
Link As".  If I left click to initiate a download, the file is saved under a
random 8-character name (with the correct file extension) in the Windows temp
folder.
It isn't just the name that shows up in the progress dialog, it is the file it
will become.  I have to go to the Windows temp directory and rename and move the
file unless I use the right-click context menu to download.

I don't know if bug 55690 is the cause of this, but this is the consistent
behavior on my installation

Comment 22

[Christopher Galey]

I no longer have this bug.  I don't know if it was just fixed in this build
(2001100708) or if I was using the wrong method of upgrading Mozilla. 
Previously, I was downloading the Win32 talkback zip file and extracting
overwriting existing files.  To fix another problem that I developed, I decided
to delete the Mozilla directory and install using
mozilla-win32-installer-sea.exe.  I can now download as expected.

Comment 23

[Bill Law]

Thanksk for the good news.

Comment 24

[[e-mail]]

Wow, that actually works! Thanks for finding that out, Chris.

Could this have been caused by left-over components such as nativapp.dll?