03-11-2022 05:54 AM
Managing PDF downloads and viewing has become a big problem with version 89. I am a programmer who has been working on healthcare applications for a few years and there are scenarios where it is convenient to download and in others where it is convenient to preview the document. These scenarios vary from application to application, but also within the same application. So these types of behaviors should be left to whoever designs the application, not to the browser. Today I have a lot of pissed off customers because it is no longer possible to download a PDF file without previewing.
06-18-2022 12:01 PM
Same problem. I don't want to view pdf documents in the browser, I have dedicated apps for that. Unfortunately I cannot change the default action. Even worse: When opening a pdf document in the browser it is automatically downloaded to a default place and occupies storage there. Moving it to the dedicated order requires additional clicks - which is imho completely unnecessary.
06-21-2022 10:38 AM
@Wux2000 wrote:Same problem. I don't want to view pdf documents in the browser, I have dedicated apps for that. Unfortunately I cannot change the default action.
What happens when you try the steps in this article: https://support.mozilla.org/kb/view-pdf-files-firefox-or-choose-another-viewer
Even worse: When opening a pdf document in the browser it is automatically downloaded to a default place and occupies storage there. Moving it to the dedicated order requires additional clicks - which is imho completely unnecessary.
If you select the "Always Ask" option, Firefox 98+ will download the file to your "Save files to:" folder when you choose "Open with [relevant application]". Firefox 102 will bring an option for Windows and Linux users to return to using the system Temp folder for that if you prefer the way it worked before Firefox 98.
07-01-2022 12:47 AM
I have same news,
with last update 102 all file are save without exstension. 😭
07-02-2022 06:30 PM
@roxpec wrote:with last update 102 all file are save without exstension. 😭
I can't stand it anymore! it is not sustainable that every small update there are such blocking problems.
That is strange.
Is this related to the issue of the PDFs that are served with Content-Disposition: attachment that Firefox started opening in a new tab -- saving from the new tab loses the .pdf file extension?
Or is this for other kinds of downloads?
A user on the Mozilla Support forum reported that downloads of .exe files from one site are renamed with a .bin extension. We haven't figured out what is causing that, but it sounds like there must have been some change related to file extensions between Firefox 101 and 102.
07-03-2022 10:01 AM
Hi jscher2000,
Thanks for answering me.
I found the problem. It seems that Firefox102 adds the file extension according to the value of the contained ContentType response header . I did some tests (pdf download), in particular by setting ContentType:
So I went back to the starting point, the solution you had always suggested(ContentType = application/x-download-pdf) in this discussion is no longer valid.
I don't think that only my application needs to view a draft of a report in PDF and make the dowlown of the final report in PDF. So as already mentioned if there are specifications to follow there is no problem the importance that these specifications are valid over time and above all those who develop the application have the faculty to choose the desired behavior. For example, the PDF displayed in the previous image has the uninhabited printing and also the "Saveas" but PDF.JS allows you to print anyway. In fact PDF.JS is another component to improve.
Thank you
07-03-2022 12:40 PM
Sorry about that, I didn't expect to make it worse.
When I test, Firefox treats it as a PDF based on the filename in the Content-Disposition header:
https://www.jeffersonscher.com/res/servepdf.php?f=bugzilla-home.pdf&ct=application/x-download-pdf
So fooling the PDF detector in this way seems to have stopped working in Firefox 102 and I agree there is no more point to that workaround if you are setting a *.pdf file name -- and obviously omitting the file name causes other problems.
Regarding printing: It's true that PDF.js doesn't honor copy and print restrictions. If you are using an embedded viewer and you need to control the available features, you can load the PDF.js library (or possibly another JavaScript library that renders PDFs) on your site and control exactly what buttons are shown on the toolbar. https://github.com/mozilla/pdf.js/wiki/Setup-PDF.js-in-a-website
07-04-2022 08:53 AM
I report my last test.
By setting the headers as follows:
Content-disposition : attachment; filename="myFile.pdf"
ContentType: x-download-pdf
the PDF viewer opens in a new tab and at the same time the download is made
07-07-2022 09:29 AM
The pdf problem seems to be related to a bug reported 14 years ago and fixed on FireFox 98
https://bugzilla.mozilla.org/show_bug.cgi?id=453455
other interesting links
https://bugzilla.mozilla.org/show_bug.cgi?id=1769368
https://bugzilla.mozilla.org/show_bug.cgi?id=1778021
12-01-2022 05:06 AM
For me this answer did the job: https://connect.mozilla.org/t5/discussions/firefox-98-pdf-dowload-and-view/m-p/10876/highlight/true#...
04-23-2024 11:25 AM
Late Update
Firefox 118 introduced a new user preference to prevent Firefox from auto-opening PDFs that are sent with "Content-Disposition: attachment" when the user has the default "Open in Firefox" action for PDFs. This doesn't help from the server side, unfortunately.
If it's something an individual (or company, by group policy) wants to implement, the preference is "browser.download.force_save_internally_handled_attachments". Note that "browser.download.open_pdf_attachments_inline" needs to have its default value of false.