1726501 - Internal PDF Reader is always used when called from a local HTML file

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

[Frank Storm]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I have some local HTML file which contain links to local PDF files. E.g
file:///home/frank/mypdffiles.html
and inside mypdffiles.html
<a href="mypdffile.pdf">my PDF file</a>

Actual results:

Since Firefox 91 only the internal PDF viewer is used to open these PDF files. The application settings are completely ignored. I can select "Always ask" or "Open with mypdfviewer", but this setting is ignored.
For remote files HTML pages, the behavior is as expected. But not for local HTML files.

Expected results:

The application settings should also be valid for local HTML files, not only for remote web pages.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Timea Cernea [:tbabos][inactive]]

Hi Frank,
I can also reproduce this issue on all the latest Firefox versions on Windows10 x64. I am not quite sure if this is expected or not but will move it over to it's component so developers can also check it out and offer a technical opinion.

Comment 3

[:Gijs (he/him)]

This was a deliberate decision in bug 1680147, because the "always ask" case didn't actually let you open the files in Firefox from the dialog (the option in the dialog didn't work if you actually used it). If the default is "save to disk", creating copies of the PDFs that are on file: also didn't make much sense. If you open other local files from a file:/// page that Firefox can handle natively, like images, we will also just open them in Firefox. So it seemed consistent to do the same for PDFs, and this was a much simpler solution than fixing the behaviour when opening the file with Firefox through the "always ask" dialog.

There are a few ways of addressing your workflow here:

• You can still get prompted for what to do with the file by clicking the download button in the PDF preview once that's open
• If you set pdfjs.disabled to true in about:config, things will go back to prompting you what to do - and will do that everywhere. But of course this also means PDF.js will be unavailable in general.

Can I ask what your usecase is here? Why not open the PDFs directly from the viewer you want? Why use Firefox as (effectively) a glorified filepicker - while not wanting Firefox to show you the things you're opening? :-)

Comment 4

[Frank Storm]

Actually I don't want being asked in this case. I want to open the PDF file in another PDF viewer (okular in this case). But this also does not work. As said, the application setting is completely ignored.

My usecase: I have a large collection of manually created web-pages that are shortcuts to local and remote documents. For example, if I start a new project, I put links to all relevant documents or web-sites onto a single page. So a click onto the link opens the file in a PDF-viewer while still keeping my project page in the foreground.
This is my way of working since several years and it is actually a big time-saver for me. The workaround with the download button is an additional action which sums up in the end (mental load, you know).

And saving a file to a different location on the same file system can also be useful, if the original file is buried deep inside a directory hierarchy.

Does this make sense for you? Btw, I cannot imagine that leaving the decision up to the user does any harm.

Comment 5

[jscher2000]

Similar scenario of locally saved HTML page with file:/// links to PDFs on SUMO today: https://support.mozilla.org/questions/1347907

It sounds like something along these lines would accommodate users with this kind of index page:

• "Open in Firefox" => use pdf.js and user can use download button
• "Always Ask" => [Fx91 behavior] use pdf.js and user can use download button
• "Save File" => [Fx91 behavior] use pdf.js and user can use download button
• "Use OS default application" => [change from Fx91] launch in that application
• "Use [specified application]" => [change from Fx91] launch in that application

I am not very familiar with this code, and my understanding of variable scope is rudimentary. In principle, though, is it possible to modify _validateAndMaybeUpdatePDFPrefs() to check the schemes in this test:

// If the user has indicated they want to be asked or want to save to
// disk, we shouldn't render inline immediately:
if (alwaysAskBeforeHandling || preferredAction == saveToDisk) {
  return false;
}

https://searchfox.org/mozilla-central/source/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1071

If this test did not return false for (channelURI?.schemeIs("file") && triggeringPrincipal?.schemeIs("file")) it seems that would allow execution to continue to the external app handling tests.

Comment 6

[:Gijs (he/him)]

(In reply to Frank Storm from comment #4)

And saving a file to a different location on the same file system can also be useful, if the original file is buried deep inside a directory hierarchy.

Well, maybe if you can choose the location where it's saved, less so if every file link you click automatically gets copied to the default Downloads folder...

Does this make sense for you?

Sort of, thank you...

Btw, I cannot imagine that leaving the decision up to the user does any harm.

Unfortunately it did do harm to users, that's what I tried to explain in comment #3: it meant that the choice of opening in Firefox itself, which we show in the "always ask" dialog, didn't actually work (it would log an error and do nothing). That's why we made this change. I missed that the patch I wrote to accomplish this would break things for people relying on "always open with external app [something]".

(In reply to jscher2000 from comment #5)

Similar scenario of locally saved HTML page with file:/// links to PDFs on SUMO today: https://support.mozilla.org/questions/1347907

It sounds like something along these lines would accommodate users with this kind of index page:

(snip)

Yes, this should work.

I am not very familiar with this code, and my understanding of variable scope is rudimentary. In principle, though, is it possible to modify _validateAndMaybeUpdatePDFPrefs() to check the schemes in this test:

// If the user has indicated they want to be asked or want to save to
// disk, we shouldn't render inline immediately:
if (alwaysAskBeforeHandling || preferredAction == saveToDisk) {
  return false;
}

This code looks like it's doing the right thing (saying "don't show this directly in PDF.js"), it's the code further down, once we return from _valdateAndMaybeUpdatePDFPrefs that overrides this and does the wrong thing, unfortunately. I'll see what we can do.

Comment 7

[:Gijs (he/him)]

(In reply to Frank Storm from comment #4)

Actually I don't want being asked in this case. I want to open the PDF file in another PDF viewer (okular in this case). But this also does not work. As said, the application setting is completely ignored.

The workaround with the download button is an additional action which sums up in the end (mental load, you know).

To be clear, I assume this means you could set pdfjs.disabled in about:config and that does do what you want, as it sounds like you never actually want to show PDFs directly in Firefox? Can you confirm if that works?

Comment 8

[:Gijs (he/him)]

Attachment: Bug 1726501 - don't use pdf.js for file: links when the user has configured an external app as the default handler for PDFs, r?mtigley

Comment 9

[Frank Storm]

Yes, I can confirm that setting pdfjs.disabled to true solves the problem and the PDF file is opened with the external viewer (okular). That actually solves the problem. Many thanks!

Unfortunately it did do harm to users, that's what I tried to explain in comment #3: it meant that the choice of opening in Firefox itself, which we >show in the "always ask" dialog, didn't actually work (it would log an error and do nothing). That's why we made this change.

Hm, I'm not sure whether I fully understand the problem. From a users perspective there is no real difference between a local and a remote web-page. It contains a link to a PDF file that I want to open in my external app, because this is what I have specified in the settings. And it has always worked that way for years. From a programmers perspective I can think of a view different ways how to implement this. The easiest way would be to create a local copy into the cache structure, as if the file would have been downloaded and then continue in the same way as if the file would have come from remote. Yes, it would be an unnecessary copy, but in the end that's a problem of the cache handling mechanism. The advanced solution would be to call the external app directly with the file path.

Comment 10

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/51b82c5e5890

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Given how late we are in the current Fx92 cycle, let's let this bake a bit and aim to ship in the next cycle.

Comment 13

[:Gijs (he/him)]

Comment on attachment 9237316 [details]
Bug 1726501 - don't use pdf.js for file: links when the user has configured an external app as the default handler for PDFs, r?mtigley

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: User confusion / user preferences not being respected
• User impact if declined: ^^
• Fix Landed on Version: 93
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Straightforward JS-only patch that's baked a while now.
• String or UUID changes made by this patch: Nope

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9237316 [details]
Bug 1726501 - don't use pdf.js for file: links when the user has configured an external app as the default handler for PDFs, r?mtigley

Approved for 91.2esr.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/12d839a5a9c8

Comment 16

[Bogdan Maris, Desktop Test Engineering]

Reproduced the issue with an old Nightly build from 2021-08-18, verified that the local pdfs are now opened using the external apps or default app set up in Firefox preferences from a local html using latest 93.0b9 and latest ESR91 from treeherder.
Testing was done on all platforms, Windows 10, Ubuntu 18.04 and macOS 11.5.