527817 - Downloading from a CGI whose output specifies a Content-Disposition: attachment; filename="foo.txt" header no longer works

Status: RESOLVED INVALID

(Firefox :: File Handling, defect)

Description

[Ed Sabol]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

I've developed an intranet-only CGI application which outputs in a variety of different formats based on user-selection. Specifically, it can output in HTML, plain text, and Excel formats using (mod_perl) code like the following:

	  $m->clear_buffer;
	  $r->content_type('application/vnd.ms-excel');
	  $r->header_out("Content-Disposition" => qq{attachment; filename="${filename}.xls"});
	  $m->flush_buffer;
	  print $ss->data;
	  $m->flush_buffer;

This worked just fine in all Firefox and Mozilla versions prior to 3.5, and it works fine in Safari, Chrome, Opera, and Internet Explorer.

In Firefox 3.5.x (and confirmed with latest 3.5.5), when I click on the link to download either plain text or Excel format, I get the usual dialog which says

You have chosen to open
foo.txt
which is a: plain text document
from: http://my.work.server....

What should Firefox do with this file?

( ) Open with ....
(x) Save File

etc.

When I click the "OK" button, the dialog goes away, but nothing happens. I would expect the downloaded file to appear in my downloads directory and for an entry to appear in the Downloads window logging the details of the download, but the file doesn't appear and nothing is displayed.

Upon further investigation, I noticed that a temporary file is created at /tmp/RANDOMSTRING.types.part which contains the download.

In previous versions of Firefox, the file would appear in my downloads directory and in the Downloads window with the file name specified by the server (foo.txt in the example above).

Reproducible: Always

Steps to Reproduce:
1. Download a non-HTML content type from a CGI with Content-Disposition:attachment; filename="foo.txt" header
2. Click the radio button next to "Save File" if that's not already selected.
3. Click the "OK" button.
Actual Results:  
File is not downloaded to the downloads directory, and no entry appears in the Downloads window. A temporary file is left at /tmp/RANDOMSTRING.types.part.

Expected Results:  
The file should download to the configured downloads directory and an entry should appear in the Downloads window logging the details of the download.

This as a regression from all versions of Firefox prior to 3.5.

I tested it on Mac OS X, and the problem did NOT occur there. This is apparently a Linux-only problem. I haven't tested on Windows.

Tested on RHEL 5.3.

Comment 1

[Ed Sabol]

I just noticed the following output on stderr when testing in safe mode:

*** exception in validateLeafName: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsILocalFile.create]"  nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame :: file:///software/linux/usr1/local/firefox-3.5/components/nsHelperAppDlg.js :: anonymous :: line 292"  data: no]

The "Save files to" directory specified in Firefox Preferences -> Main is definitely writeable....

Comment 2

[Matthias Versen [:Matti]]

Your reports looks like bug 429827 (the exception in comment #77 is the same)

Comment 3

[Ed Sabol]

Maybe, although that exception appears to be from Thunderbird and the line number is different.

Also, I'm 100% positive that my browser.download.dir exists and is writeable. It's not on an external drive either. *shrug*

I'll see if I can apply that bug's patch to see if it helps though. Thanks for the pointer.

Comment 4

[Matthias Versen [:Matti]]

Do you have this issue only with your downloads or with all downloads ?
What happens if you change the preferences for the file save to ask every timer where to download the file (no default location) ?

Comment 5

[Ed Sabol]

Belated follow up on this bug.... It turns out I think this was due to a corrupted sqlite file in my profile. Actually, I think pretty much all of the sqlite files in my profile were corrupt. I deleted the ones that were corrupt and the problem went away when I restarted Firefox. Closing this bug. Thanks for taking a look, Matthias.