I am using M12 on WinNT sp5. I have also reproduced this in the Linux version of M12. You can test the problem at the URL given above. The filename should be "fm._$$". When downloading a file from a url that does not have the filename in the URL, the default filename is set to the html filename of the webpage sending the file. Here is the header sent to the web browser about the file: Content-Disposition: attachment; filename=fm._$$ Content-Type: application/octet-stream Content-Length: 89765 <actual data from file>

Sairuh, is there another bug on this?

oh yeah --this sounds like bug 16043. however with that one it only occurred on Mac and linux. bill, what d'you think?

Yep, this is a dup. Changing bug #16043 to reflect the cross-platform nature of the bug. *** This bug has been marked as a duplicate of 16043 ***

This is a completely different bug than 16043. That bug is simply deficiencies in the Mac/Linux implementations of nsIFileWidget. This bug is more complicated. The web server is providing the "suggested" file name and somehow we've got to get this passed from the networking code to the file picker. That's going to require a completely different fix (but will be dependent on 16043 if the fix is to work on Mac/Linux).

Updated the URL (added http:// and corrected what I think was a typo).

M14 ...

Clearing DUPLICATE resolution due to reopen.

I tested the 01-20-2000 nightly build on Linux and WinNT to see if BUG fix 16043 fixed this bug. The problem still exists.

tested using opt comm bits [2000022308] on linux, mac and winNT. i no longer see this problem going to the URL above. marking as wfm. however, pls lemme know if you still see this!

tested fine with another url: http://ftp.mozilla.org/pub/mozilla/releases/m13/mozilla-win32-installer-M13.exe

I tried the problem URL listed in the header with the Feb-24-2000 10:15am build on WinNT and I still see this problem. I will test with Linux tonight.

this is still a problem. thanks, bill, for your explanation! (sorry about the loooong delay.) Subject: Bugzilla bug 22861 Date: Thu, 24 Feb 2000 15:55:48 -0800 From: law@netscape.com (Bill Law) To: sairuh@netscape.com Just to clarify this bug: The problem is that the http server is sending a content-disposition tag in the header that specifies a file name. We *should* be respecting that file name when we put up the file picker. We don't do that. We do suggest a name (generated from the URL), but it's the wrong one. This bug will be fixed when the suggested file name shows up in the native file picker as "fm._$$".

This also happens when using M14 (which lists Mozilla/m13 in HTTP_USER_AGENT???) on WinNT4/sp6a. I have a local test page which says "Content-disposition: inline; filename=something.exe" and Mozilla does not respect that - it still pulls down the wrong file with wrong name (i.e. the referring file, instead of the targeted file). NS and IE both work fine with the page, so I guess Mozilla would be better off by behaving the same way...

Move to M16 ...

Reassigning for Don

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

This bug was causing problems with Net2Phone downloads initiated from pr1 (the n2p page was using this technique in the response from a cgi to get the file stored with extension ".exe"). It must be fixed so we don't have the problem in pr2.

Putting on [nsbeta2+] radar for beta2 fix.

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

cc:shrir

Move to M18 target milestone.

These patches will support the following... o L10N support of components/xfer o Rewrite from nsFileWidget to nsIFilePicker since nsFileWidet and nsFileSpec is obsolute. o Fix a little I18N problem. o Support Content-Disposition. See comments of uriloader.

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

Thank you very much for the patches. Unfortunately (or fortunately, since I can conclude that we both did things right) they look more or less the same as the ones I have developed this week myself. I'm waiting for review of my patches and will be checking them in as soon as I get reviewer's OK.

Bill, your changes work for me on Linux. I looked over the changes too and they look good. r=slamm

Fix checked in.

law, your code is a few problem. nsFileSpec is obsolete. We should use nsILocalFile. Because nsFileSpec isn't I18N safe. See bug 42173. But, my patch is included in fix code.

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

used 2000.06.14.08-m17 commercial bits to test this on all/all. when i click the URL, then click Save As in the Unknown File Type dialog, i do get the Save File dialog where the filename is fm._$$. if that's the extent of this bug, fine i'll verify this. however, after clicking OK in the Save File dialog, i get the download progress window...which never updates... is this a known bug? if not, should i open another bug or reopen this one? thx

I get the same behaviour with build 2000061408 on WinNT. The filename shows correctly, but the progress window never updates and the file never downloads. the file fm._$$ is actually a gif file(the mozilla logo), so when you download it, open it up in a graphics editor to make sure it downloaded sucessfully. I think we need to reopen the bug, but I would rather the QA person working on this bug make the decesion. Our builds might not have the full patch for all I know.

Please don't reopen this bug (at least not for the reason cited). Download is broken in many ways so I don't want to hold this bug hostage because of that. In particular, recent changes to this code causes it to now use nsIFilePicker whose implementation on Windows has a serious heap corruption flaw (see bug 42384). This could be causing the problem. I have that bug fixed on my machine and I don't see the problem reported here.

thx, bill... vrfy this.

Reopening. The problem now exists in the new "super helper app dialog" case (e.g., click on the link, get the "Downloading" dialog, choose Save To Disk).

Somehow this just got fixed in the helper app dialog. If you select Save instead of open, you are prompted with a save as dialog that uses this as the default selection.

a-yup, fixed on winnt/linux/mac [2000.09.18.05/6/8 opt comm].