When PDF download behaviour is set to "Always Ask", choosing "Open In Firefox" stores the file to the default downloads directory
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: pg_78, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
-
In about:preferences >> Files and Applications >> Applications, set the Action for application/pdf to "Always Ask"
-
Navigate to a PDF file (such as https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf)
-
In the dialog which asks you what you want to do with the file, select "Open in Firefox"
Actual results:
- The PDF file opens in the Firefox PDF viewer, but is stored in the user's default download directory
Expected results:
The same behaviour as if you had configured the application action in about:preferences to "Open In Firefox", i.e. the file opens in the PDF viewer but is not saved to the default download dir.
As discussed in bug 1759779 (https://bugzilla.mozilla.org/show_bug.cgi?id=1759779#c15), the current behaviour does not seem to be optimal.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•3 years ago
|
|
|
||
Comment 2•3 years ago
|
||
I believe this is the cause. That from here. Looks like this is related to bug 1680147 so I'm gonna mark it. Upon closer inspection, this doesn't look like an easy fix, it's kind of like an architectural issue because we need to make decisions about what to do with the stream before the user has interacted with the dialog.
|
||
Comment 3•3 years ago
|
||
(In reply to pg_78 from comment #0)
The same behaviour as if you had configured the application action in about:preferences to "Open In Firefox", i.e. the file opens in the PDF viewer but is not saved to the default download dir.
This is not possible for technical reasons. We don't have a "CANTFIX" resolution, so I guess I'll pick "invalid" as the next best thing.
|
|
||
Comment 4•3 years ago
|
||
(In reply to Shane Hughes [:aminomancer] from comment #2)
I believe this is the cause. That from here. Looks like this is related to bug 1680147 so I'm gonna mark it. Upon closer inspection, this doesn't look like an easy fix, it's kind of like an architectural issue because we need to make decisions about what to do with the stream before the user has interacted with the dialog.
This is exactly it - if the user says they want a dialog, the bytes that are being sent to us by the server need to go somewhere in the meantime. The file could be really big, and there's no guarantee the user will react to the dialog quickly (or that the download is "slow" rather than on fibre and so handing you several 10s of MBs every few seconds) so just keeping it all in memory also doesn't really work. So it gets stored, the same way as it does for the other preference cases. "Open in Firefox" as the preferred action is special because we can assume that we handle things internally and take some shortcut, but the same assumptions don't hold for "always ask".
(In reply to :Gijs (he/him) from comment #4)
The file could be really big, and there's no guarantee the user will react to the dialog quickly (or that the download is "slow" rather than on fibre and so handing you several 10s of MBs every few seconds) so just keeping it all in memory also doesn't really work.
Thanks (and also to :aminomancer) for the illuminating explanations and the code.
I don't have super-strong feelings about this issue, because I can live with setting "Open in Firefox" as the default and saving from the PDF viewer if I want the file to end up on my filesystem, or indeed just right-clicking and choosing "Save Link As..." if I know from the outset that I want to keep the file.
But genuine question: what if, given that we know that the file is a PDF from its mime type, we just assume that it can be held in memory until the user reacts to the dialog? Clearly there's an assumption there - AFAIK there's no logical upper bound on how big a PDF could be - but is it an assumption that isn't actually already made when "Open in Firefox" is the preferred actions for PDFs? (I might be wrong, since I don't know the details of the shortcuts that happen in that case.)
|
|
||
Comment 6•3 years ago
|
||
(In reply to pg_78 from comment #5)
(In reply to :Gijs (he/him) from comment #4)
The file could be really big, and there's no guarantee the user will react to the dialog quickly (or that the download is "slow" rather than on fibre and so handing you several 10s of MBs every few seconds) so just keeping it all in memory also doesn't really work.
Thanks (and also to :aminomancer) for the illuminating explanations and the code.
I don't have super-strong feelings about this issue, because I can live with setting "Open in Firefox" as the default and saving from the PDF viewer if I want the file to end up on my filesystem, or indeed just right-clicking and choosing "Save Link As..." if I know from the outset that I want to keep the file.
But genuine question: what if, given that we know that the file is a PDF from its mime type, we just assume that it can be held in memory until the user reacts to the dialog? Clearly there's an assumption there - AFAIK there's no logical upper bound on how big a PDF could be - but is it an assumption that isn't actually already made when "Open in Firefox" is the preferred actions for PDFs? (I might be wrong, since I don't know the details of the shortcuts that happen in that case.)
We technically could, but it would be very involved. We'd need to specialcase this situation (file is a PDF + always ask is selected), deal with the memory usage (we'd need some kind of upper bound, I guess?) and the cases where we then need to write it to disk after all before handing it off to another program (including then writing the rest of the data that arrives to that file, as well as ensuring we use temp files in the same secure way we do for downloads more generally to avoid driveby attacks), and somehow pass it to the pdf viewer directly instead of writing to disk if "Open in Firefox" does end up eventually being selected (we couldn't reuse the existing mechanism which relies on the PDF viewer code handling the network data directly itself, which also progressively loads/shows the PDF...). That is a substantial amount of work, basically reimplementing most of the download logic for this specific case, and it'd be pretty fragile. The trade-off there doesn't seem worth it, maintenance-wise, just to avoid the file being saved to disk...
(In reply to :Gijs (he/him) from comment #6)
(we couldn't reuse the existing mechanism which relies on the PDF viewer code handling the network data directly itself, which also progressively loads/shows the PDF...).
Got you, that's the big thing I was missing, I think. Thanks!
|
|
||
Comment 8•3 years ago
|
||
I think given that you can just set it to "Open in Firefox" and then click the save button in the PDF.js interface if you want to save the file after all, it's probably not worth trying to adapt the UCT dialog for this case. It's already nice to be able to see the PDF while you're deciding whether you want to save it or not. I work with Acrobat all the time for my work, but I also view PDFs (with no intention of saving them) a bit more frequently. The current "Open in Firefox" behavior is really nice for that just due to the speed. I actually use Firefox as my OS default PDF handler now, since it's just so much faster than Acrobat or Acrobat Reader, at least for when I don't need to do any serious editing.
Description
•