inconsistent behavior for PDF files served as application/force-download




8 years ago
3 years ago


(Reporter: vincent-moz, Unassigned)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv: Gecko/20110218 Firefox/3.6.14
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv: Gecko/20110218 Firefox/3.6.14

For a PDF document served as application/force-download, Firefox recognizes the file as PDF, but doesn't suggest to open the document with the default PDF viewer as it does for files served as application/pdf.

Reproducible: Always

Steps to Reproduce:
1. Open

Actual Results:  
A dialog appears saying:

You have chosen to open
which is a: Portable Document Format
What should Firefox do with this file?
* Open with [Choose...]

Expected Results:  
Since Firefox recognizes the file as Portable Document Format, it should propose the default application for PDF files.

But one may wonder whether to recognize the file as PDF is OK. Information should come from the Content-Type header.

Similar problem under Linux.

Also note that the user cannot be aware of the difference between application/pdf and application/force-download, since such information isn't shown. In both cases, Firefox just says "Portable Document Format". So, the user should expect the same behavior.

For this file, the HTTP response is:

HTTP/1.1 200 OK
Date: Thu, 03 Mar 2011 00:47:54 GMT
Server: Apache/1.3.34 (Unix) mod_gzip/ PHP/4.4.2 mod_ssl/2.8.25 OpenSSL
X-Powered-By: PHP/4.4.2
Content-Disposition: attachment; filename=C1C2.pdf
Content-Transfer-Encoding: binary
Content-Length: 811499
Pragma: no-cache
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/force-download
> Since Firefox recognizes the file as Portable Document Format

The UI chooses to pick that string based on the extension.  The core code, which is what decides how to handle the data, relies entirely on the MIME type, very much on purpose.

Oer to Firefox for the confusing UI bit.
Component: File Handling → File Handling
Product: Core → Firefox
QA Contact: file-handling → file.handling

Comment 2

7 years ago
The bug still occurs with:

  Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20100101 Firefox/10.0.4 Iceweasel/10.0.4

The URL given in the bug report no longer works, but the following one triggers the bug:
Reproducible with the latest Nightly (build ID: 20130813155809) on a Windows 7 64bit machine, with the URL from comment 2.
Ever confirmed: true

Comment 4

3 years ago
This bug is still present in Firefox 42 running on Windows 7 x64 machine.

Returned MIME type when upload a PDF file is 'application/force-download'. I tested with Chrome and everything works OK.

Please, fix it.


Comment 5

3 years ago
This bug is still present in Firefox 44 running on Windows 7 x64 machine.

Please, fix it.


Comment 6

3 years ago
It appears to me, that it is now impossible to open local PDF files with Firefox in Windows 10, after installing "Cumulative update for Windows 10: September 13, 2016". Any local PDF, being dropped to the Firefox window, causes "Save as" dialogue. Even when Firefox is set as default app for PDF files in Windows settings. And there is no option to open preview. 

Maybe this update makes all local PDF files to have MIME type of "application/force-download" or something. PDF files from the internet, which have a type of "application/pdf" , are opened in the Firefox internal PDF viewer, as always.

Comment 7

3 years ago
It turned out, that the behavior mentioned above probably was not caused by Cumulative update. For unknown reason, new code appeared mimeTypes.rdf. I never edited the file nor installed any PDF software recently. The following code in the mimeTypes.rdf made Firefox unable to preview PDFs:

  <RDF:Description RDF:about="urn:mimetype:application/force-download"
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/force-download"/>

Probably, it somehow was added automatically after downloading PDF from some website (as mentioned in )
You need to log in before you can comment on or make changes to this bug.