User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20151208030212 Steps to reproduce: Open a URL corresponding to a PDF file. Actual results: I got the attached dialog box, which says that the file is a PDF document, though an inspection of the HTTP headers (but this needs an extension) gives: application/octet-stream Without the HTTP headers, this is confusing because Firefox does not offer to open the file with an external PDF viewer. Expected results: Firefox should give correct information.
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 20151208030212 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 20151208030212 (In reply to Vincent Lefevre from comment #0) > Expected results: > > Firefox should give correct information. The information is correct: the file type is PDF. Content-Type: application/octet-stream doesn't offer any details about the file type; it simply means “download this”. Firefox can identify PDFs based on something other than the MIME type sent by the server. https://developer.mozilla.org/en-US/docs/How_Mozilla_determines_MIME_Types#Unknown_Decoder > Firefox does not offer to open the file with an external PDF viewer. Looks like a regression of bug 327323, which was itself a regression. It works on Windows, but it's reproducible in Linux Mint.
Status: UNCONFIRMED → NEW
Component: Untriaged → File Handling
Ever confirmed: true
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → All
Summary: Firefox lies about the document type in the "Opening..." dialog box → "Open with" option missing for files sent as Content-Type: application/octet-stream
For https://www.vinc17.net/test/mozbug-649321.pdf (which was used for bug 649321), served as application/binary but where the file is also identified as PDF, Firefox wants to open it with GIMP, which is also incorrect because the configured default on my machine is xpdf. According to the Application Preferences, this is "Always Ask / Use xpdf (default)".
Cannot reproduce comment 2 in Linux Mint KDE: Firefox suggests opening the file with Okular, the application associated with PDFs.
Concerning my test in comment 2, on a different machine (information for myself: cventin), whether I use Iceweasel 38 (which I was using on the first machine) or Firefox 42, xpdf (default) is proposed as expected, even with a fresh profile. GIMP is also installed on this machine. So, I don't understand the difference.
I've eventually found the reason concerning comment 2: cventin:~> xdg-mime query default application/pdf xpdf.desktop zira:~> xdg-mime query default application/pdf gimp.desktop So, there are several problems: 1. Inconsistency between application/binary (which gives an "Open with" option) and application/octet-stream (which doesn't). 2. When an "Open with" option is provided, the Firefox preferences about:preferences#applications are not honored. Firefox seems to use xdg-mime instead. 3. The helpers.private_mailcap_file mailcap file is not honored either, but this may be a consequence of (2).
This bug needs updating. Currently, "Open with" option will appear. But the problem is, if you choose any application other than default, that choice won't be saved. Next time you open a file, it will still choose the default application. For example, for https://www.vinc17.net/test/mozbug-649321.pdf , I click it first. It asks me what application to open with, where the default is "Adobe acrobat DC" I have. If I chose something else, for example Foxit reader, it will open that with Foxit reader for this time. If I click that link again, it will goes back to Adobe Acrobat DC and Foxit reader does not even appear in the drop-down menu.
(In reply to Benjamin Peng from comment #6) > This bug needs updating. I see no difference in the latest Nightly. > Currently, "Open with" option will appear. Like I said at comment 1, it works on Windows. That's why I set this report as Linux-specific.
Thanks, I didn't read carefully. I will open another ticker for what I observed.
You need to log in before you can comment on or make changes to this bug.