Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

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

Adobe Acrobat Pro DC's 'Attach to Email' returns error if .PDF file is opened via Firefox's download library.

  • 4 replies
  • 1 has this problem
  • 1 view
  • Last reply by A.S.

more options

Adobe Acrobat: 2015.006.30498 Firefox 68.0.1 64-bit Outlook 2016 16.0.4849.1000 64-bit Windows 10 1803

The issue: When a user downloads a .PDF file with Firefox and opens the file via the 'downloads library' it opens the file in Adobe Acrobat Pro DC. When the user then attempts to use the 'Attach to Email' function in Acrobat, it returns the error "the file "[location of users Outlook .OST file]" is in use and cannot be accessed. Close any application that is using this file, and then try again. You might need to restart the computer.

The issue does not present itself if the .PDF file, downloaded via Firefox is opened from the 'File Explorer' download folder. (EG by clicking the corresponding 'folder' icon next to the download, then opening the .PDF file from there or by any other means of accessing the file in question through File Explorer)

There are also no issues downloading .PDF files and attaching them in the same manner, using other browsers or their versions of the download manager. (IE, Edge, Chrome)

This issue has appeared on two computers tested so far and is repeatable/persistent.

I suspect that the message regarding the .OST file is a bit of a red herring. I think the FF downloads library window is somehow locking the PDF opened through it and thus causing an error when attempting to pass the file over to Outlook to send as an attachment.

Any assistance regarding this would be appreciated.

Adobe Acrobat: 2015.006.30498 Firefox 68.0.1 64-bit Outlook 2016 16.0.4849.1000 64-bit Windows 10 1803 The issue: When a user downloads a .PDF file with Firefox and opens the file via the 'downloads library' it opens the file in Adobe Acrobat Pro DC. When the user then attempts to use the 'Attach to Email' function in Acrobat, it returns the error "the file "[location of users Outlook .OST file]" is in use and cannot be accessed. Close any application that is using this file, and then try again. You might need to restart the computer. The issue does not present itself if the .PDF file, downloaded via Firefox is opened from the 'File Explorer' download folder. (EG by clicking the corresponding 'folder' icon next to the download, then opening the .PDF file from there or by any other means of accessing the file in question through File Explorer) There are also no issues downloading .PDF files and attaching them in the same manner, using other browsers or their versions of the download manager. (IE, Edge, Chrome) This issue has appeared on two computers tested so far and is repeatable/persistent. I suspect that the message regarding the .OST file is a bit of a red herring. I think the FF downloads library window is somehow locking the PDF opened through it and thus causing an error when attempting to pass the file over to Outlook to send as an attachment. Any assistance regarding this would be appreciated.

Chosen solution

Hi A.S., I can't replicate that with Acrobat 2017 and Outlook (latest for Office365). But I'll speculate anyway.

Firefox 68 has a new launch(er) process that seems to affect some helper programs. When a user is running with admin privileges, the launcher process in Firefox 68 now runs the browser with only standard user privileges (medium integrity) instead of full admin privileges (high integrity). When you open a download from the Downloads list, the helper application seems to inherit the reduced privileges under which Firefox is running, and that can have unexpected side effects.

Workaround?

If that is the problem, there is a workaround to force Firefox to run with full user privileges. Whether you decide to do this depends on how much of an inconvenience this is for your user versus the security benefits of the browser being able to do less damage to the system if it becomes compromised.

You could test it to see whether my theory is the explanation. If not, it must be something else.

Here's how:

The simplest method would be to modify your Firefox program shortcut (assuming you start Firefox from the program shortcut, and not from a link). Either:

  • Right-click a Firefox desktop shortcut, then click Properties
  • Right-click a Firefox icon pinned to the Taskbar then right-click Mozilla Firefox, then click Properties

Windows should show the Shortcut tab and select the Target field. The Target usually is along the following lines:

  • "C:\Program Files\Mozilla Firefox\firefox.exe"
  • "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"

You would add a space and then the new switch, either:

  • "C:\Program Files\Mozilla Firefox\firefox.exe" -no-deelevate
  • "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -no-deelevate

This will take effect the next time you exit out of Firefox and start it up again using the shortcut. Any difference?

More info on the launcher process: https://wiki.mozilla.org/Platform/Integration/InjectEject/Launcher_Process/

Read this answer in context 👍 1

All Replies (4)

more options

Chosen Solution

Hi A.S., I can't replicate that with Acrobat 2017 and Outlook (latest for Office365). But I'll speculate anyway.

Firefox 68 has a new launch(er) process that seems to affect some helper programs. When a user is running with admin privileges, the launcher process in Firefox 68 now runs the browser with only standard user privileges (medium integrity) instead of full admin privileges (high integrity). When you open a download from the Downloads list, the helper application seems to inherit the reduced privileges under which Firefox is running, and that can have unexpected side effects.

Workaround?

If that is the problem, there is a workaround to force Firefox to run with full user privileges. Whether you decide to do this depends on how much of an inconvenience this is for your user versus the security benefits of the browser being able to do less damage to the system if it becomes compromised.

You could test it to see whether my theory is the explanation. If not, it must be something else.

Here's how:

The simplest method would be to modify your Firefox program shortcut (assuming you start Firefox from the program shortcut, and not from a link). Either:

  • Right-click a Firefox desktop shortcut, then click Properties
  • Right-click a Firefox icon pinned to the Taskbar then right-click Mozilla Firefox, then click Properties

Windows should show the Shortcut tab and select the Target field. The Target usually is along the following lines:

  • "C:\Program Files\Mozilla Firefox\firefox.exe"
  • "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"

You would add a space and then the new switch, either:

  • "C:\Program Files\Mozilla Firefox\firefox.exe" -no-deelevate
  • "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -no-deelevate

This will take effect the next time you exit out of Firefox and start it up again using the shortcut. Any difference?

More info on the launcher process: https://wiki.mozilla.org/Platform/Integration/InjectEject/Launcher_Process/

more options

Your solution worked perfectly. Thanks!

more options

Are the problem downloads stored on a mapped network drive or UNC share instead of locally? I'm just wondering whether there is some factor that would explain why I couldn't replicate it.

more options

On the first PC I tested the downloads were directed onto a network drive. On the second they're just on the local disk. So that didn't seem to make a difference in recreating the issue.