Portable Document Format (PDF) preference 'Open file' in FF, it opens the file even when downloading is expected
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: LD_Squad_Swap, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.86
Steps to reproduce:
1st case:
Click on the link of 1. Example of href link standard usage.
2nd case:
Open and click on the link of 2. Example of href link with the 'download' attribute.
3rd case:
Click on the hyperlink of 3. Example of href link with 'download' and 'type' attributes.
4th case:
Click on the link of 4. Example of PDF file download with JavaScript.
Actual results:
When using an href link without any attribute, FF opens the file.
When using an href link with the 'download' attribute, it downloads the file but also opens the PDF document.
Expected results:
When using an href link without any attribute, FF opens the file.
When using an href link with the 'download' (HTML5) attribute, it should just download the file.
Note1 : The current issue lies in the automation of PDF files opening, which is not a standard web or cross-browser behavior
Note2: In version Firefox 102, we did not have this type of behavior
|
||
Updated•2 years ago
|
|
Reporter | |
Comment 1•2 years ago
|
||
|
|
Reporter | |
Comment 2•2 years ago
|
||
Hello Bugzilla Community,
This bug relates tu download feature we're providing to our 5000 insurance company end users.
Previous 102 ESR version user experience was fine.
With 115, we're facing to productivity and human error issues.
Any help will be appreciated in august as we're expected tu deploy before end of septembre (102 support deadline...).
Xavier - product owner @ Maif - French Insurance company
|
||
Comment 3•2 years ago
|
||
In the screencast, you can see that Firefox does download the PDF. We then open it automatically from disk (the URL in the address bar is file:///...), because that is how Firefox is set up: always open PDFs. This behaves the same way as other filetypes set up to open with external applications (or Firefox).
(In reply to Squad_Swap from comment #0)
Note2: In version Firefox 102, we did not have this type of behavior
This is confusing to me, because in my testing, 102 behaves the same way and I'm not aware of significant changes to the default behaviour. Can you doublecheck? Perhaps you're applying specific preferences or enterprise policy to make it behave differently?
|
|
Reporter | |
Comment 4•2 years ago
|
||
|
|
Reporter | |
Comment 5•2 years ago
|
||
:Gijs As you can see in the sample html file we provided, you have 3 links based on HREF tag and the last one is about downloading file with javascript.
Only the first link opens the pdf file because the HREF tag doesn't include 'download' keyword.
If you run this sample in Chrome, you'll notice that even if the pref "Open pdf files in Chrome" is set, it will not open the file but just only download it. That is the standard behavior according to the code we set in HREF tag (i.e if the keyword 'download' is present, the link must execute a download and nothing more and if not it opens the file).
If FF-115 opens the file after having downloaded it, in my opinion, it doesn't respect the code anymore.
|
|
||
Comment 6•2 years ago
|
||
(In reply to Squad_Swap from comment #5)
If FF-115 opens the file after having downloaded it, in my opinion, it doesn't respect the code anymore.
The 'download' attribute doesn't mean that the user agent is not allowed to open the file once opened, if the user configured it that way. Firefox used to always show a dialog in this case ("What do you want to do with this file") which gave the user a direct choice. That dialog also allowed opening files, and what's more, we used to default to saving the file in a temporary directory, which meant it got deleted later. (By now, the default is to save in the default downloads folder instead.)
The ironic thing is that there are also still people unhappy because we download the file at all, and they would want the file to never be on disk in this case, which is the opposite of what you're asking for... Either way, the "best" behaviour is not really as clear as you make it out to be.
If you run this sample in Chrome, you'll notice that even if the pref "Open pdf files in Chrome" is set, it will not open the file but just only download it. That is the standard behavior according to the code we set in HREF tag (i.e if the keyword 'download' is present, the link must execute a download and nothing more and if not it opens the file).
If you set Chrome up to always open a specific filetype other than PDFs (word documents or whatever), then links to such files with a download attribute will also open after they are downloaded. Firefox has chosen to apply the same behaviour to PDFs, and has done this for all files for some time now - see bug 453455 for all the requests relating to this in general.
Changing Firefox's behaviour wrt pdfs sent with Content-Disposition: attachment and/or download attributes would require either regressing bug 453455 or changing how we process all download attributes, or creating a PDF specialcase for this (probably with yet another user control to override it to obtain the same behaviour as now, which is preferred by some users). That kind of significant behaviour shift, combined with a requirement for user interface changes, would require product management and UX design support and won't happen by September. It's also probably a duplicate of an existing bug.
I understand that you don't like this behaviour for PDFs, but Firefox has behaved like this for a long time (differently from Chrome), also in 102esr, as far as I know. I would like to understand better if you're seeing something different on 102esr. If we broke something, that would perhaps be fixable sooner. So I'd like to ask again if you're really seeing something different on 102 or if perhaps that was on the previous ESR version (91) or earlier.
|
|
Reporter | |
Comment 7•2 years ago
|
||
:Gijs In our previous version (Firefox 102ESR), we had set the parameter browser.download.improvements_to_download_panel to true when we wanted to save the PDF. This allowed the PDF to save directly to the folder without opening the viewer. However, this parameter no longer functions. Additionally, we are experiencing multiple issues with applications that do not want PDFs to open, as this action results in the creation of numerous tabs and many more clicks.
On standard websites like outlook.com, gmail.com, or sharepoint, the file download feature saves files to the download directory without providing a preview.
The panel menu briefly appears to confirm that the operation was successful.
This behavior is consistent with what's seen in the Edge and Chrome web browsers.
Sincerely,
QA - Roberto
|
|
||
Comment 8•2 years ago
|
||
(In reply to Squad_Swap from comment #7)
:Gijs In our previous version (Firefox 102ESR), we had set the parameter browser.download.improvements_to_download_panel to true when we wanted to save the PDF.
Do you mean "false" instead of "true" here? (as "true" is the default value)
|
|
Reporter | |
Comment 9•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #8)
(In reply to Squad_Swap from comment #7)
:Gijs In our previous version (Firefox 102ESR), we had set the parameter browser.download.improvements_to_download_panel to true when we wanted to save the PDF.
Do you mean "false" instead of "true" here? (as "true" is the default value)
In version 102, we set the 2 values:
"browser.download.improvements_to_download_panel": false,
"browser.download.panel.shown": false,
And the download panel worked correctly.
Currently, we've tried to modify and re-modify, but we haven't been able to prevent the display and download of PDFs.
|
|
Reporter | |
Comment 10•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #8)
(In reply to Squad_Swap from comment #7)
:Gijs In our previous version (Firefox 102ESR), we had set the parameter browser.download.improvements_to_download_panel to true when we wanted to save the PDF.
Do you mean "false" instead of "true" here? (as "true" is the default value)
Hi Gijs,
We've answered to your question on friday. sorry for the little mistake.
Do you think we could expect gettng those preferences reactivated short terme as have to deploy our 5000 users end of september this year (ESR102 mozilla support deadline).
If not, we would like o discuss Open in Firefox fearure enhancement request:
This option is the only one enabling web applications to separated vizualization or downloading features depending on business requirements.
Using standard HREF URLs , documents are viewed in Firefox pdf viewer. Tha’s fine !
Currently, if HREF download option is setted, then FF execute download process AND opens the document in FF PDF Viewer. This last step is not required, time consuming, in our webapps and softwares like Microsoft Outlook/Sharepoint to offer a quick download features.
That’s what we would like to offer to our 5000 users. A way to simplify UX and conform to HTML5 standards.
If you think this can help, we’re available for a visio call. Just consider our location (France).
Xavier
|
||
Comment 11•2 years ago
|
||
Most probably a duplicate of bug 1772569. This last one is marked as fixed and closed by the way, even though it seems the bug is still present.
|
|
||
Comment 12•2 years ago
|
||
(In reply to Squad_Swap from comment #10)
(In reply to :Gijs (he/him) from comment #8)
(In reply to Squad_Swap from comment #7)
:Gijs In our previous version (Firefox 102ESR), we had set the parameter browser.download.improvements_to_download_panel to true when we wanted to save the PDF.
Do you mean "false" instead of "true" here? (as "true" is the default value)
Hi Gijs,We've answered to your question on friday. sorry for the little mistake.
Hello, yes, sorry, I've been travelling and in all-day meetings (and in fact am still travelling).
Do you think we could expect gettng those preferences reactivated short terme as have to deploy our 5000 users end of september this year (ESR102 mozilla support deadline).
No. Support for them was removed completely. They were temporary feature flags while we worked on the overall changes to the download flow. If we do anything we would need to write new code to cater to this usecase.
(In reply to PomCompot from comment #11)
Most probably a duplicate of bug 1772569. This last one is marked as fixed and closed by the way, even though it seems the bug is still present.
No, this isn't a duplicate of that issue. That bug complained because it wanted the "download" case described in this bug treated exactly the same as the inline case (so no download at all, whereas right now there is a download + open). We put this behind a pref (browser.download.open_pdf_attachments_inline) that defaults to false.
Instead I think this is strictly speaking a dupe of bug 1811830.
(In reply to Squad_Swap from comment #10)
Currently, if HREF download option is setted, then FF execute download process AND opens the document in FF PDF Viewer. This last step is not required, time consuming, in our webapps and softwares like Microsoft Outlook/Sharepoint to offer a quick download features.
So, we're talking about this internally but don't have a conclusion at the moment. As I said before, this works the way it does because of bug 453455, which before it was closed was the most-duplicated-request in this bugtracker for the Firefox product: users expect that if they tell the browser "always open [files of type X]", that they open. Also if the website says "download". This same behaviour was applied to PDFs, like any other filetype - but PDFs are defaulted to "open with Firefox". There is not currently a way to tell Firefox "treat PDFs with a download header like a download, and open PDFs without that header inline (like a normal webpage) in the PDF viewer".
We'll update bug 1811830 with whatever conclusion we reach.
In the interim, perhaps you could consider:
- setting PDFs to "always ask" so users can decide for each PDF whether they want to download it or no;
- setting PDFs to "save to disk" so they always download
You could also probably write an extension that auto-closes these opened PDF tabs, if you so chose.
That’s what we would like to offer to our 5000 users. A way to simplify UX and conform to HTML5 standards.
The HTML standard does not govern what happens to a downloaded file once it is downloaded (ie whether it is subsequently opened or not), so I don't think this question relates to the standard at all. It relates to what the user expects in this situation. From that perspective, what the other browsers do by default is probably more important, though it is also odd to treat PDF differently from all the other filetypes.
(In reply to Squad_Swap from comment #9)
"browser.download.improvements_to_download_panel": false,
So finally, just to clarify this for future reference: we made a large number of changes to the downloads behaviour in the Firefox 97 timeframe (1.5 years ago!). We developed those changes behind a feature flag (this pref). When we decide a feature like this is stabilized, we remove the pref and the now obsolete code, because otherwise we have to keep maintaining 2 codepaths forever (multiplied by however many of these feature flags we have). We may be slow in removing the pref, but eventually it always happens. If you find yourself turning off things like this to fix workflow issues you experience, please please please tell us about these workflow issues immediately when you turn it off, rather than waiting until we remove the pref, because at this point it's very very difficult for us to provide you with reasonable support - the code is gone and we really don't want to bring all of it back as it governs much more than just this PDF behaviour.
|
|
Reporter | |
Comment 13•2 years ago
|
||
Hi Gijs,
You’re right, we should have contributed to bugzilla discussions regarding this pref in addition to qualifying ESR once a year… lesson’s learned.
We’ve considered « always ask » and « save to disk » options.
They don’t work as they also interfer with simple visualization requests.
We’ve 2 applications integrating the FF PDF viewer. In both cases, visualization appears in a new window (outside the application) or doens’t appear at all.
Very short term, we’ll POC a web extension as recommended, also considering potential performance and security impacts.
We’ll contribute to the 1811830 - Treat PDF like browser native file types (mozilla.org) discussion.
|
|
Reporter | |
Comment 14•2 years ago
|
||
Hi Gijs,
We'll update bug 1811830 with whatever conclusion we reach.
We hope that the conclusion would be at least to bring back to a simple behavior ; i.e open means open and download just download.
In the interim, perhaps you could consider:
setting PDFs to "always ask" so users can decide for each PDF whether they want to download it or no;
setting PDFs to "save to disk" so they always download
This can not apply to our situation as we have applications that open the pdf files in a viewer (might be Firefox Viewer) and those that just download them without viewing.
You could also probably write an extension that auto-closes these opened PDF tabs, if you so chose.
We have investigated in writing an extension but we are facing a difficulty to distinguish a downloading context vs a viewing one (but any suggestions would be nice).
As this issue is closed, we'll contribute to that one 1811830.
Description
•