Stop downloading PDFs and making URLs hard to find
Adding this post for SEO indexing purposes, as I cannot reply to the original archived one: https://support.mozilla.org/en-US/questions/1321170
The original post is one of the top search engine results, and provides a bandaid solution, without addressing the proper root cause, so I want to help whoever stumbles over this.
Original problem:
Dale 1/9/21, 8:26 AM
Firefox Developer Edition 85.0b4, macOS 10.15
If I Google for a PDF and click a link, I get the Firefox download dialog. If I select "Open with Firefox [Developer Edition]", the following things happen:
The PDF is downloaded to ~/Downloads The PDF is opened in a new tab, with that new tab's location bar holding a file:///... URL to the downloaded PDF
What I would instead like to happen is:
The PDF is downloaded to some temporary directory where I won't have to worry about deleting it manually In whatever tab the PDF is displayed in, the location bar contains the URL where the PDF was (temporarily!) downloaded from
How can I achieve this?
Not having the URL where a PDF was opened from is very annoying when, for example, I open a bunch of PDF search results to read and review, and I later want to share links to some of those PDFs. Best I can do to find their URLs to give to others is then to try and remember which tab corresponds to which search result, or do mine the downloads tab.
Contrast this with Chrome: I click a Google result for a PDF and the PDF just opens in the current tab with the URL to the PDF in the location bar. No dialogs, no PDF files hanging around in my home directory, and I can just copy the URL to the PDF the same way I'd copy the URL to any web page.
Thank you!
Proposed solution by original poster:
Dale Question owner 1/9/21, 9:27 AM Chosen Solution
Sigh. It appears the problem was one or both of the following preferences:
pdfjs.enabledCache.state: false pdfjs.migrationVersion: 2
I deleted both, and now clicking on a PDF just opens in the sane, normal way in Firefox that I desire.
Naturally I have no idea how those got set.
All Replies (1)
الحل المُختار
Root cause and proposed correct solution:
The two preferences pdfjs.enabledCache.state and pdfjs.migrationVersion are internal state tracking values managed automatically by Firefox and the PDF.js module during initialization. They are not feature flags and are not intended to be manually set or removed. Restarting the browser will always restore them to whatever Firefox determines they should be, so any manual edits are ephemeral.
For the same reason, the original fix suggested in the referenced post is only addressing symptoms. It works once, then the browser undoes it on the next restart. This is not a path worth pursuing.
pdfjs.enabledCache.state is a cached result. It records whether PDF.js is currently registered as the default handler for PDF files. Firefox determines this at startup by querying the MIME handler service, checking two conditions:
alwaysAskBeforeHandling = false preferredAction = handleInternally (value 1, "open in browser")
If both are true, pdfjs.enabledCache.state is set to true or removed from prefs.js entirely, which is the healthy state. If either condition fails, it's set to false, and PDF.js does not consistently intercept PDF files to open them.
The reason this check is failing is that handlers.json, Firefox's MIME handler registry, has no entry for application/pdf set to handleInternally. Usually this entry gets created the first time a user interacts with a PDF download dialog. If this is missing or set to any other option, PDF.js will not consistently intercept PDF files for displaying them in browser.
This can be addressed consistently either through settings and handlers associations, or using the policies mechanism provided by Firefox.
The Handlers enterprise policy for configuring MIME type associations could be a first stop as it can write entries to handlers.json through the proper internal API. https://firefox-admin-docs.mozilla.org/reference/policies/handlers/ However, its available actions are limited to saveToDisk, useHelperApp, and useSystemDefault. handleInternally is not exposed, so it cannot be used to register PDF.js as the handler.
Instead a dedicated policy specifically for PDF.js configuration, aptly named PDFjs, can be considered, and it is a one-stop-shop: https://firefox-admin-docs.mozilla.org/reference/policies/pdfjs/
This policy handles everything needed in one step: enabling PDF.js, registering the correct handleInternally PDF entry in handlers.json, and allowing Firefox to correctly manage enabledCache.state and migrationVersion values going forward.
These two entries should be added in the Firefox policies config file:
DisableBuiltinPDFViewer = false
PDFjs = {"Enabled": true, "EnablePermissions": true}
The DisableBuiltinPDFViewer is a legacy policy which does exactly what it sounds like from the name. Even though legacy, it is not deprecated, so I recommend having it set to false, for configuration consistency and reliability purposes. It will basically re-enforce what the PDFjs policy does. https://firefox-admin-docs.mozilla.org/reference/policies/disablebuiltinpdfviewer/
After setting this, the results are consistent:
pdfjs.disabled set to false pdfjs.migrationVersion correctly set to 2 pdfjs.enabledCache.state absent from prefs.js (healthy state) application/pdf entry present in handlers.json with handleInternally value set (1) PDF files reliably open in the browser with no download-to-disk occurrences
You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.