1680147 - Opening local pdfs from file:///... fails if PDFs are set to "always ask"

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Screenshot from 2020-12-02 01-10-28.png

Download (for example)
http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf

Go to the url pointing to the directory where the file was saved
Something like file:///home/<user>/Downloads
Click the pdf.
Dialog opens to let user to choose what to do with the pdf. Select "Open with Nightly".

That doesn't succeed, and an error dialog is shown.

Comment 1

[Calixte Denizet (:calixte)]

I can reproduce easily in nightly in selecting "Always ask" for pdf in "Applications" section.
:gijs, maybe you'd have an idea here on what's wrong.

Comment 2

[:Gijs (he/him)]

(In reply to Calixte Denizet (:calixte) from comment #1)

I can reproduce easily in nightly in selecting "Always ask" for pdf in "Applications" section.

Thanks for specifying this. The problem does not occur when picking "open in Firefox", which is the default for PDFs.

:gijs, maybe you'd have an idea here on what's wrong.

Not off-hand. I will try to investigate later this week.

Comment 3

[:Gijs (he/him)]

So we avoid this if you open the PDF externally or with system principal, because we hit this code:

https://searchfox.org/mozilla-central/rev/bf8d5de8528036c09590009720bc172882845b80/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1123-1130

and allow handling directly with PDF.js

In this case, the triggering principal is a file principal (because that's where the link is!) and so we don't allow immediate opening with PDF.js . Which means we end up showing the "what do you want to do" dialog.

When the user picks Firefox in the dialog, we hit launchWithFile in the mime info implementation. This implementation is OS-dependent but either way it checks the "preferred action" (which is "handle internally") which it doesn't know how to do, so it returns NS_ERROR_INVALID_ARG, which causes the failure and dialog:

Windows: https://searchfox.org/mozilla-central/rev/bf8d5de8528036c09590009720bc172882845b80/uriloader/exthandler/win/nsMIMEInfoWin.cpp#88
macOS: https://searchfox.org/mozilla-central/rev/bf8d5de8528036c09590009720bc172882845b80/uriloader/exthandler/mac/nsMIMEInfoMac.mm#29
other: https://searchfox.org/mozilla-central/rev/bf8d5de8528036c09590009720bc172882845b80/uriloader/exthandler/nsMIMEInfoImpl.cpp#280

I'm not sure whether/how we should update them for this case, and if there are any other ways of triggering them besides this quirk of pdf.js-ness. Perhaps with the other file types where we now support handling them internally? But then, why would we ever show the dialog for them when clicking a file: link for them? Adam, you worked on the other filetypes - do you have any thoughts?

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1680147 - open file: links to PDFs from file: pages with PDF.js immediately

Comment 5

[:Gijs (he/him)]

https://phabricator.services.mozilla.com/D116915 fixes this by immediately opening in PDF.js instead of opening the dialog first, but I don't know if the removal of the choice to use an external app in this case is going to upset anyone who somehow relies on using this to open external apps...

Comment 6

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(In reply to :Gijs (out; back Jun 21; he/him) from comment #3)

I'm not sure whether/how we should update them for this case, and if there are any other ways of triggering them besides this quirk of pdf.js-ness. Perhaps with the other file types where we now support handling them internally? But then, why would we ever show the dialog for them when clicking a file: link for them? Adam, you worked on the other filetypes - do you have any thoughts?

I don't think the same thing can happen with the other types, though I don't understand fully the PDF issue here. When opening the other types from file: they always display regardless of whether we're set to always ask or to use a system handler. I tried the download attribute on a link, doesn't seem to work for file:, I think because same-origin checks are weird with file:.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b929d6015258
open file: links to PDFs from file: pages with PDF.js immediately r=mtigley

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b929d6015258

Comment 9

[Ciprian Georgiu, Desktop QA]

I've reproduced this issue on mac 11, using an affected Nightly version (2020-12-01), and by following the steps from comment 0.

Hi Gijs! Just to make sure that I understand correctly this fix, the local pdf files will be opened immediately in Firefox, without prompting the dialog to the users, even though the "Always ask" option is checked for pdf. Is that correct? I've verified this on Win 10 x64, macOS 10.11 and Ubuntu 18.04 x64 with Beta 91.0b9.

Comment 10

[:Gijs (he/him)]

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #9)

I've reproduced this issue on mac 11, using an affected Nightly version (2020-12-01), and by following the steps from comment 0.

Hi Gijs! Just to make sure that I understand correctly this fix, the local pdf files will be opened immediately in Firefox, without prompting the dialog to the users, even though the "Always ask" option is checked for pdf. Is that correct? I've verified this on Win 10 x64, macOS 10.11 and Ubuntu 18.04 x64 with Beta 91.0b9.

yep, that's correct!

Comment 11

[Ciprian Georgiu, Desktop QA]

Thank you! We can then close this bug as verified fixed, since I encountered that behavior on latest Beta 91, as mentioned in comment 9.

Comment 13

[Micah [:mtigley] (she/her)]

Attachment: Bug 1680147 - Rename LaunchWithApplication to SetDownloadToLaunch. r=gijs!

Comment 14

[Phabricator Automation]

Comment on attachment 9251710 [details]
Bug 1680147 - Rename LaunchWithApplication to SetDownloadToLaunch. r=gijs!

Revision D131714 was moved to bug 1740142. Setting attachment 9251710 [details] to obsolete.