8330 - When file downloaded, file name lost

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[cpratt]

Build ID: 1999061608
Platform: Windows NT

To reproduce:
- Go to the above URL to download Communicator 4.61 English
- When the Download button is clicked, the Unknown File Type box comes up
- Click Save File
- Note that the file navigation dialog shows no name for the file - it should

Comment 1

[Gagan]

Necko landing...

Comment 2

[James Everingham]

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9.  We will need to get on this and it cannot be postponed past the M9
milestone.

Comment 3

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 4

[Gagan]

Not networking related. Whoever is throwing the Save As dialog box needs to
query for the file name from the URI using GetFileName(&filename). Not sure if
XPApps gets it... but they'd know...

Comment 5

[Andrew Stone]

Attachment: This is the file with the bug fixed.

Comment 6

[Andrew Stone]

The attached file fixes the bug, and it adds a starting download directory
to the user preferences.  When this patch is applied, this new feature won't
work (but this bug will be fixed), because I also need an enhancement request
done (there is a bug filed but my computer just crashed so I forgot the
number). It has to do with
nsIFileSpecWithUIImpl.cpp

This patch should be able to be applied independant the other bug and vice
versa.

You need not throw the whole file in the cvs tree.  Here are the changes:

At the top I include some more files:
#include "nsIFileSpecWithUI.h"
#include "nsRepository.h"
#include "nsIPref.h"
static NS_DEFINE_CID(kPrefCid,NS_PREF_CID);

And in the middle I rewrote the function:
nsStreamTransfer::SelectFileAndTransferLocation( nsIURI *aURL, nsIDOMWindow
*parent )

If you see anything wrong, then feel free to reassign the bug to me with
a short explanation...

Thanks,
Andrew

Comment 7

[Steve Dagley]

Reassigning to law since don is the black hole of bugz

Comment 8

[Bill Law]

I incorporated the provided fixes (more or less).  This only seems to work on
Windows, however (I don't think the other platforms support either
SetDisplayDirectory or using the suggested name).

Looks like maybe this is going away anyway, in lieu of nsIFilePicker.

Comment 9

[Bill Law]

I've fixed this on our end.  nsIFileWidget implementation is deficient on Unix
and Mac.  What do I do now?  Sit on this one till nsIFilePicker is done, or
reassign?

Comment 10

[Bill Law]

Marking RESOLVED since the requisite changes to my code have been made and it
works on Windows.  There are already bugs (I think) relating to this problem on
Linux.  That bug has prompted the development of the nsIFilePicker solution,
which will ultimately fix the Mac too.

Comment 11

[sairuh (rarely reading bugmail)]

verified as fixed with 1999-12-02-11-m12 on NT.