1706871 - Impossible to download / read some PDF files

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P2)

Description

[Alessio Placitelli [:Dexter]]

Since a few Nightlies (sorry, I don't have the exact regression window!) - we're currently at 90.0a1 (2021-04-20) - it is impossible to download some PDF files in order to read or view them. The problem appears to be frequently happening on origins that serve the file over HTTP instead of HTTPS.

Steps to reproduce:

1. Initiate a PDF download from a HTTP origin (e.g. this is failing for me).
2. The "Download" panel from the toolbar will show an entry for the file, mentioning that download was blocked because of a security risk. Clicking the icon to get more informations, I'm asked to either "Open" (or "Save") the file or "Delete it".
3. Clicking "Open" (or "Save") does not initiate the action. Instead the file is marked as "Failed" in the download panel.

Expected behaviour:

At step (3) I should be able to open or save the PDF file, after having acknowledged the risks.

Comment 1

[Thorin [:thorin]]

Is this a duplicate of Bug 1686756 ? ... comments 7 and 8

The download takes more than 3 seconds and is thereby cancelled by the http-background request. --> Bug 1683015

---

The flag for nsILoadInfo::HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS does not get set before dom.security.https_only_mode_send_http_background_request cancels the request

Alessio, is the issue solved if you set dom.security.https_only_mode_send_http_background_request to false

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Simon Mainey from comment #1)

Is this a duplicate of Bug 1686756 ? ... comments 7 and 8

The download takes more than 3 seconds and is thereby cancelled by the http-background request. --> Bug 1683015

---

The flag for nsILoadInfo::HTTPS_ONLY_TOP_LEVEL_LOAD_IN_PROGRESS does not get set before dom.security.https_only_mode_send_http_background_request cancels the request

Alessio, is the issue solved if you set dom.security.https_only_mode_send_http_background_request to false

No, looks like the problem is still there if I flip that pref to false (even after restarting Nightly).

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

Hey Alessio, thanks for reporting. I finally got around to test using your STRs.

Can you please double check, using this STRs.
(1) Click this link which will open the PDF Viewer.
(2) On the right hand side in the Menu, click the Download button
(3) Panel appears, hit safe file
(4) On top right hand side, the download icon turns red, click that icon and you should see File not downloaded: potential security risk
(5) Click on the info button and Download Details appear
(6) Click Allow Download and file should be downloaded

Is that what you experience as well? Or is there something I am missing?

Comment 4

[Alessio Placitelli [:Dexter]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #3)

Hey Alessio, thanks for reporting. I finally got around to test using your STRs.

Can you please double check, using this STRs.
(1) Click this link which will open the PDF Viewer.
(2) On the right hand side in the Menu, click the Download button
(3) Panel appears, hit safe file
(4) On top right hand side, the download icon turns red, click that icon and you should see File not downloaded: potential security risk
(5) Click on the info button and Download Details appear
(6) Click Allow Download and file should be downloaded

Is that what you experience as well? Or is there something I am missing?

I can't reproduce the problem in Nightly anymore :O

Comment 5

[Marco Bonardo [:mak]]

If instead of download I pick "Open" in the dialog, I can reproduce.

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Marco Bonardo [:mak] from comment #5)

If instead of download I pick "Open" in the dialog, I can reproduce.

Marco, thanks for testing. I just tried your suggestion using the latest mozilla-central code again (Basti used Nightly) and we both can't reproduce that problem anymore. Can you do us a favour and test on your end again - thanks so much!

Comment 7

[Marco Bonardo [:mak]]

Attachment: TinyTake06-05-2021-01-17-30.mp4

It actually requires an additional step, that is to set the handler as Always Ask.
In this video I'm setting pdf to always ask, and when asked I choose to open. I suppose it would also work with other types.
After this, if I click on retry it just instantly fails.

Comment 8

[Sebastian Streich [:sstreich]]

Attachment: Bug 1706871 - Fix HandleInternally + Insecure Downloads r=mak

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a713faa51ebb
Fix HandleInternally + Insecure Downloads r=mak

Comment 10

[Iulian Moraru]

Backed out for causing bc failures on browser_test_mixed_content_download.js.

Push with failures

Failure log

Backout link

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:sstreich, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0f01ac89ab32
Fix HandleInternally + Insecure Downloads r=mak

Comment 13

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/0f01ac89ab32

Comment 14

[Monica Chiorean]

I was able to reproduce the issue using Win 10 and build 90.0a1.
Verified as fixed on Win10, Mac and Ubuntu 20.4 using Beta 95.0b4(20211107190147).