Comment 8 for bug 245776

I have got this a couple of times with PDF files. The file is downloaded, it can be found intact in the tmp directory, but it will not open with the default Document viewer. IIRC, explicitly selecting a viewer (/usr/bin/xpdf of /usr/bin/evince) opened the document fine.

Right now I cannot reproduce the problem exactly, but can get similar results:
1. Create a new firefox profile for testing and use that.
2. Browse to a pdf document that is served using an unknown, wrong content-type, e.g., 'application/x-foobar'.
3. Select "Open with Document Viewer (default)
-> Gives error message "/tmp/test.pdf could not be opened, because the associated helper application does not exist. Change the association in your preferences."
4. Doubleclick (or select retry) for the entry in the download manager
-> Gives the error message: "/tmp/test.pdf could not be saved, because you cannot change the contents of that folder."

FF3 is giving the wrong error message here. Probably the same applies to the original problem. There is of course nothing that ties this to some specific file type like pdfs or debs.

I am attaching a simple python script to easily serve files in the current directory using whatever content-type. Use it like:
MIMETYPE=application/x-foobar python mthttpserver.py
and then browse to http://localhost:8000/

On a side note, why does FF3 offer the default viewer when it knows there is no associated helper?