PDF is downloaded unexpectly by using "Open with Firefox" in "Always ask" option
Categories
(Firefox :: File Handling, defect)
Tracking
()
People
(Reporter: exploratory666, Unassigned)
Details
Attachments
(1 file)
9.21 MB,
video/quicktime
|
Details |
[Affected versions]:
99.0.1 (64-bit)
101.0a1 (64-bit)
[Affected Platforms]:
macOS 10.15.7 (19H524)
[Steps to reproduce]:
- Click the "hamburger menu" button.
- choose "Settings".
- Set "Always ask" option in "Applications" for "Portable Document Format".
- Open any site with embedded PDF.
- Choose "Open with Firefox".
- Click the "OK" button.
[Expected Results]:
Without downloading the pdf, the pdf is just viewed by Firefox.
[Actual Results]:
The pdf is downloaded and viewed by Firefox.
[Notes]:
- A new tab is opened.
- If set "Open in Firefox" option in "Applications" for "Portable Document Format", the pdf is just viewed by Firefox. I think maybe they should be consistent.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 1•3 years ago
|
||
:exploratory666, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.
Comment 2•3 years ago
|
||
(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #1)
:exploratory666, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.
Sorry, I'm a new comer. Would you please give me more details about how to get the regressed_by field?
Comment 3•3 years ago
|
||
The bot asked you because you set the "Has Regression Range" field to "yes".
Are you able to reproduce the bug in an older version of Firefox? What is the first version of Firefox where you see this behavior?
If there is a version where you can't reproduce this, you could try using https://mozilla.github.io/mozregression/ to find a regression range.
Comment 4•3 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #3)
The bot asked you because you set the "Has Regression Range" field to "yes".
Are you able to reproduce the bug in an older version of Firefox? What is the first version of Firefox where you see this behavior?
If there is a version where you can't reproduce this, you could try using https://mozilla.github.io/mozregression/ to find a regression range.
Thanks for your explanation! I just find this behavior in the version 99.0.1 (64-bit) and 101.0a1 (64-bit). Sorry, I se t this field accidentally.
Reporter | ||
Updated•3 years ago
|
Comment 5•3 years ago
|
||
This behavior seems to be related to the new download experience. I have reproduced this in 99.0.1 (64-bit) on Windows 10 (21H1), and I think Firefox 98 too (cannot confirm now). I have set "always ask" both for download location and PDF file handling.
I read a lot of PDF files in Firefox, and am slightly annoyed about them piling up in my Downloads folder. I too would expect "Open in Firefox" to not save the file (to a user-visible location, permanently) by default.
Comment 6•3 years ago
|
||
The severity field is not set for this bug.
:Gijs, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 7•3 years ago
|
||
This is a dupe.
As noted in the dupe, this is technically complex to address; more details are given there.
The default "open in firefox" behaviour (ie without the "always ask" dialog first showing) used to also download the PDF first for some PDFs (technically, for PDFs sent with Content-Disposition: attachment
), which we fixed in 98. We used to default to downloading these PDFs to the temp folder on Windows/Linux, but it's always been the downloads folder on macOS (ie this isn't a regression there). Either way, the PDF was always downloaded to disk first, so that too is not a regression - but on Windows/Linux you may not have realized this, and the file used to be deleted on Firefox shutdown.
The default downloads folder now being used (and the file not being deleted) on Windows/Linux is a change that affects all downloads (not just PDFs) and was already extensively discussed in bug 1738574. We'll potentially revisit that in the near future, so if you care about this I suggest CC'ing yourself to that bug.
Description
•