Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

how do I disable the "PDF is an executable file" warning when opening a PDF from Downloads library?

  • 11 replies
  • 1 has this problem
  • 5 views
  • Last reply by kede81

more options

I have set Firefox to ask how to handle PDFs and usually choose save, as I want to keep most of them. I do not use the internal PDF viewer. When after downloading, I open a PDF from the Downloads dropdown or from Library Downloads, I get a popup saying: "Open Executable File? “FILENAME.pdf” is an executable file. Executable files may contain viruses or other malicious code that could harm your computer. Use caution when opening this file. Are you sure you want to launch “FILENAME.pdf”? (Cancel) (Ok)" (screenshot attached) This behaviour started with Quantum I believe. Actually, my chosen PDF reader (Atril, a fork of Evince) does not support Javascript, which I assume is the reason for introducing this warning, so the warning does not apply in my case, and it is a nuisance, so I would like to disable it. How do I do so?

Note that Firefox seems to remember on a per-file basis that the warning was acknowledged, so opening the same file again from Downloads, the popup does not appear. But I want to prevent it from appearing even the first time.

For reference: the pdf definition in PROFILE/handlers.json is: "application/pdf":{"action":0,"extensions":["pdf","pdf;jsessionid=2c7663ad9dfe3b68a1b43d20aa96b70f"],"ask":true} I have set about:config browser.download.manager.alertOnEXEOpen=false with no effect on this behaviour.

Attached screenshots

All Replies (11)

more options

That's strange. You've had this for 18 months now? I don't even get anything like that for EXE files (on Windows).

Could you test in Firefox's Safe Mode? In its Safe Mode, Firefox temporarily deactivates extensions, hardware acceleration, any userChrome.css/userContent.css files, and some other advanced features to help you assess whether these are causing the problem.

You can restart Firefox in Safe Mode using either:

  • "3-bar" menu button > "?" Help button > Restart with Add-ons Disabled
  • (menu bar) Help menu > Restart with Add-ons Disabled

and OK the restart.

A small dialog should appear. Click "Start in Safe Mode" (not Refresh).

Any difference?

more options

Meant to ask:

Can you bypass the message if you:

  • click the folder icon to the right of the download on Firefox's list to open the containing folder with the PDF selected in the list
  • press the Enter/Return key to launch the PDF from that folder

Not that you should have to -- but to check whether it's an attribute of the file that may have been added during downloading.

more options

(deleted, missed that the OP is on Linux)

Modified by cor-el

more options

On Linux, an executable file would have the 'x' bit set. I don't know why this bit would have to get set on files you download.

more options

This additional file extension is a little odd:

kede81 said

For reference: the pdf definition in PROFILE/handlers.json is: "application/pdf":{"action":0,"extensions":["pdf","pdf;jsessionid=2c7663ad9dfe3b68a1b43d20aa96b70f"],"ask":true}

Does this problem only occur on sites where the file extension is perceived as more than just .pdf ?

How about this very basic link: https://www.jeffersonscher.com/temp/userChrome_css.pdf

more options

What is the default application for PDF ?

  • xdg-mime query default application/pdf
more options

Most of my downloads go into the Downloads folder. These files are created 664 (-rw-rw-r--). I download some files into a Veracrypt volume where they appear to have 700 (-rwx------) and chmod -x has no effect. But the popup appears on all PDFs regardless of the file mode.

Note that if I choose "Open with: Atril Document Viewer (default)" instead of "Save File", the popup does not appear.

as requested: $ xdg-mime query default application/pdf atril.desktop

I am convinced that my userChrome.css has no relevance: $ cat userChrome.css @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* Global UI font */

  • { font-size: 13pt !important;
 font-family: "Liberation Sans Narrow", Calibri !important ; 

} /*.tab-label-container { font-family: "Liberation Sans Narrow" !important; }*/ /* Hide Giant Thumbnail on Edit Bookmark Panel */

  1. editBookmarkPanelImage {
 display: none !important;

} /* Move Favicon up and Name down */

  1. editBookmarkPanelFavicon {
 margin-top: 4px !important;

}

  1. editBookmarkPanelContent {
 padding-top: 40px !important;

}

But my profile has a really long hostory including a platform change from Windows to Linux. This may also explain the spurious additional "extension" listed for pdf (but all PDFs from many download sites are affected so that is not the reason). I will try the safe mode at the next convenient occasion. The responses already seem to indicate to me that this is likely not a global feature applying to everyone, so I am more hopeful now that it can be fixed by examining my setup.

Also, thanks for mentioning userContent.css, which I was not previously aware of but I will experiment with in the future.

more options

Thanks for the info.

userChrome.css and userContent.css shouldn't affect downloaded files, but I wanted to let you know what is changed in Firefox's Safe Mode so it's less of a surprise and you don't get distracted by having to deal with the default interface.

I don't know whether it would make any difference, but you could remove that extra array item in handlers.json (and the comma preceding it) to see whether that makes any difference. Mine is:

"application/pdf":{"action":2,"extensions":["pdf"],"ask":true}

You have action 0 and I have action 2, but I don't think that should affect this issue. The action parameter can have these values:

0 = Save to File (default) 1 = Always ask 2 = Use a specified helper app 3 = Handle internally (for example, PDF Viewer) 4 = Use system default app

If the ask parameter is set to true, that seems to override the action parameter.

more options

It is likely that when ask=true, action=0 or 2 cache the most recently used choice, so that the radiobutton can be pre-set accordingly. This would be the natural place where to remember that choice.

The pdf;jsessionid=2c7663ad9dfe3b68a1b43d20aa96b70f is already present in a backup from 20181012 so it is unlikely to be of any practical use any more. I assume it is advisable to only edit this file while Firefox is not running.

more options

Yes, only while Firefox is not running. Otherwise, Firefox may well overwrite your changes.

more options

Meanwhile I was indeed able to track it down to executable being set. So my earlier assumption that it applies regardless of file mode was mistaken, and I apologize for it. I save most of my downloads into a Veracrypt volume which does not support Unix permissions and is mounted with all items being -rwx------ mode. I was able to work around the issue by using the mount option "fmask=177" (initially I foolishly set "umask=177" and could not change into any directories) but assuming I also had executables in that volume, that wouldn't be an option. I think looking at the file's executable bit is generally irrelevant when Firefox passes the filename as an argument to an external program, because the executable bit only has relevance if a filename is passed as arg0 to the exec function, which Firefox certainly doesn't when it is a parameter to the configured PDF handler, in my case atril. When atril opens the file with fopen() the executablöe bit makes no difference. Even if the handler were e.g. perl, given a script as an argument does not require the executable bit and it will be executed exactly the same whether it is set or not. So looking at the executable ("x") bit of the file and issuing a warning in this case is logically flawed.

Modified by kede81