User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

In Firefox settings, configure Firefox to always save PDF files instead of displaying them in internal viewer. Open a PDF file from Windows Explorer with Firefox (Open with ...).

Actual results:

The file was "downloaded" by Firefox, which effectively made a copy of the file with " (1)" appended.

Expected results:

I want Firefox to download PDFs when I click on a PDF link in the browser, so I configured it to always download PDFs.
But I also want to use Firefox as my default offline PDF viewer when I doubleclick on a PDF in Windows Explorer. In my opinion, the setting how to handle PDF links from within the browser should not be applied here.
Users expect Firefox to dispay the content of the PDF when they assign Firefox with PDF files. Getting a copy of the file on the harddisk instead is of no use.

If PDF.js is not manually disabled, I'm hoping this is now fixed on nightly / Firefox 78, by the patch in bug 1633790.

Fixing this for when PDF.js is disabled and/or for other file types is something we can do in this bug.

Sarah, if you were looking to apply to the downloads project, perhaps this is a bug where you'd be able to contribute a fix? You should be able to reproduce based on comment #0 - in the Firefox settings, search for "PDF" and set it to always save to disk. Then, in about:config look for pdfjs.disabled and set it to true. Then close Firefox and see if you can reproduce the issue from comment #0.

Hi @Gijs
Thanks! Will be much obliged...
Kindly assign.

I just (In reply to :Gijs (he/him) from comment #2)

Sarah, if you were looking to apply to the downloads project, perhaps this is a bug where you'd be able to contribute a fix? You should be able to reproduce based on comment #0 - in the Firefox settings, search for "PDF" and set it to always save to disk. Then, in about:config look for pdfjs.disabled and set it to true. Then close Firefox and see if you can reproduce the issue from comment #0.

I was able to reproduce the issue.
My PDF file was downloaded instead of opening with firefox.
The download condition rule should exempt files opening with firefox from local file explorer.

(In reply to Sarah Ukoha from comment #4)

My PDF file was downloaded instead of opening with firefox.
The download condition rule should exempt files opening with firefox from local file explorer.

Well, the desired behaviour if PDF.js is disabled (and we therefore cannot open the file ourselves) for local files should be to prompt. And although this applies to PDFs when PDF.js is disabled, it should apply to other files more broadly: if we are asked by the OS to open a local file, automatically downloading it to create a second copy of that file doesn't really make sense. We should ask the user what they want to do.

The code for this lives in C++ in https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp . Look for the cases where we use nsIMIMEInfo::saveToDisk. We should enforce that alwaysAsk is set to true if and only if we would normally save to disk automatically, but the source of the download is a file channel.

(Because this is a C++ issue, to fix this and test the fix you'll need a local build that's not an artifact build.)

(In reply to :Gijs (he/him) from comment #5)

(In reply to Sarah Ukoha from comment #4)

My PDF file was downloaded instead of opening with firefox.
The download condition rule should exempt files opening with firefox from local file explorer.

Well, the desired behaviour if PDF.js is disabled (and we therefore cannot open the file ourselves) for local files should be to prompt. And although this applies to PDFs when PDF.js is disabled, it should apply to other files more broadly: if we are asked by the OS to open a local file, automatically downloading it to create a second copy of that file doesn't really make sense. We should ask the user what they want to do.

The code for this lives in C++ in https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp . Look for the cases where we use nsIMIMEInfo::saveToDisk. We should enforce that alwaysAsk is set to true if and only if we would normally save to disk automatically, but the source of the download is a file channel.

(Because this is a C++ issue, to fix this and test the fix you'll need a local build that's not an artifact build.)

Wow!
C++ is not exactly my playground! I can still give this a go, with proper guide, (all programming language being same in my opinion, of course). Though my lazy honest self will love to let this go :)

Thank you Micah.
I couldn't reproduce the bug in Nightly. I am not getting the option of opening pdf file with Firefox/Nightly in windows explorer.
Infact, the option of "Open in Nightly" is not present for pdf content in the settings(where I have selected "Save File"). What can I do?

(In reply to Vaidehi from comment #7)

Thank you Micah.
I couldn't reproduce the bug in Nightly. I am not getting the option of opening pdf file with Firefox/Nightly in windows explorer.
Infact, the option of "Open in Nightly" is not present for pdf content in the settings(where I have selected "Save File"). What can I do?

Yeah, had same issue for a long time, cuz the nightly instance is not actually installed. You can bouycut that by CTRL+O
and choosing the pdf file you want to open.
I think it serves same purpose.

(In reply to Vaidehi from comment #7)

Hi Vaidehi! I was having a bit of trouble reproducing this on Windows as well, but just got it to work now. What I needed to do is make sure downloads always saved to a folder destination on disk. You can find this by searching "Downloads" in Firefox settings and making sure the "Save files to..." option is selected.

the option of "Open in Nightly" is not present for pdf content in the settings(where I have selected "Save File"). What can I do?

That option should be present when the pref pdfjs.disabled is false. But for reproducing this issue, we want to set it to true, so I think this is expected.

I am not getting the option of opening pdf file with Firefox/Nightly in windows explorer.

In comment 8, Sarah mentioned you can open the downloads library dialog using CTRL+O from there you can open a PDF file in Nightly.

Hope this helps!

Hi @gijs @mtigley
I gave this a try, I think I got it this time.
Can you review please

(In reply to Sarah Ukoha from comment #10)

Hi @gijs @mtigley
I gave this a try, I think I got it this time.
Can you review please

Thanks for the patch! I left a comment on phabricator.

https://hg.mozilla.org/mozilla-central/rev/9dc679970296