-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to download pdf instead opening them in brave. Unable to disable pdf.js via command line. #1531
Comments
@Techguyprivate is this still an issue in current release? |
I'm still unable to View PDFs in |
The issue is still there. .Still pdf not getting downloaded even when setting the option to " Download PDF files instead of automatically opening them in Brave " is set to true. Brave stable |
Fixes brave/brave-browser#1531 The fix does the following: 1. Makes the initial decision on whether to load PDFJS extension based on the value of kPluginsAlwaysOpenPdfExternally profile preference. 2. Watches profile preference value kPluginsAlwaysOpenPdfExternally and adds/removes PDFJS extension when the value changes. 3. Modifies js behind the chrome://settings/content/pdfDocuments so that if the PDFJS extension is disabled from the command line the option to download PDF files instead of opening them in Brave is set to ON and the toggle is disabled. Note, that this fix doesn't address being able to turn off opening PDFs in Brave in Guest/Tor profiles. The web ui setting to do so is not available in these profiles. The command line switch to not load PDFJS already applies to all profile types.
Also reproducible on Ubuntu 18.10 (64-bit):
Setting does work, as expected (prompts download), in Chromium Browser version: |
Fixes brave/brave-browser#1531 The fix does the following: 1. Makes the initial decision on whether to load PDFJS extension based on the value of kPluginsAlwaysOpenPdfExternally profile preference in addition to the command line switch. 2. Watches profile preference value kPluginsAlwaysOpenPdfExternally and adds/removes PDFJS component when the value changes. 3. Modifies js behind the chrome://settings/content/pdfDocuments so that if the PDFJS extension is disabled from the command line the option to download PDF files instead of opening them in Brave is set to ON and the toggle is disabled. 4. Adds an alternative call for whitelisted extensions in extensions/common/manifest_handlers/mime_types_handler.h that removes Chrome's PDF Extension ID from whitelisted IDs and patches chrome/browser/plugins/plugin_utils.cc to use the alternative call. This is done because on Linux that extension is not removed from profile enabled extensions (because there is no extensions install verification) and it ends up being picked as a handler for PDFs. If our PDFJS extension is disabled via command line, this causes a PDF to be neither displayed nor downloaded. Note, that this fix doesn't address being able to turn off opening PDFs in Brave in Guest/Tor profiles. The web ui setting to do so is not available in these profiles. The command line switch to not load PDFJS already applies to all profile types. Adds browser tests to check that when the preference is set to always download or PDFJS is disabled from command line a download is initiated when navigating to a pdf url.
Related: #1778 (allow disabling PDF.js in settings) |
Fixes brave/brave-browser#1531 The fix does the following: 1. Makes the initial decision on whether to load PDFJS extension based on the value of kPluginsAlwaysOpenPdfExternally profile preference in addition to the command line switch. 2. Watches profile preference value kPluginsAlwaysOpenPdfExternally and adds/removes PDFJS component when the value changes. 3. Modifies js behind the chrome://settings/content/pdfDocuments so that if the PDFJS extension is disabled from the command line the option to download PDF files instead of opening them in Brave is set to ON and the toggle is disabled. 4. Adds an alternative call for whitelisted extensions in extensions/common/manifest_handlers/mime_types_handler.h that removes Chrome's PDF Extension ID from whitelisted IDs and patches chrome/browser/plugins/plugin_utils.cc to use the alternative call. This is done because on Linux that extension is not removed from profile enabled extensions (because there is no extensions install verification) and it ends up being picked as a handler for PDFs. If our PDFJS extension is disabled via command line, this causes a PDF to be neither displayed nor downloaded. Note, that this fix doesn't address being able to turn off opening PDFs in Brave in Guest/Tor profiles. The web ui setting to do so is not available in these profiles. The command line switch to not load PDFJS already applies to all profile types. Adds browser tests to check that Chromium's PDF extension is not considered for handling PDFs and if the PDFJS extension is not loaded or disabled from command line a download is initiated when navigating to a PDF URL. Also adds test to verify that when PDF download preference is toggled the component loader will take an appropriate action (add or remove PDFJS extension).
Verification passed on
Used Test plan from brave/brave-core#941 Verified passed with
|
Verification only passed for manual enabling the switch in
|
@srirambv, I tested on Mint 19 Cinnamon with the command line switch and navigating to a pdf link results in a download prompt. |
Description
I always download pdf instead of opening them in browser. Going to content setting in chrome://setting , toggling the option to download pdf instaed of opening them, doesn't work.Pdf gets opened in browser. Unable to disable Pdf.js extension component via command line.No toggable option in extension setting .It is greyed out.
Steps to Reproduce
Actual result:
Pdf file is opening inside brave ,instead of getting downloaded.
Expected result:
Pdf file should be downloaded in brave, instead of opening inside the browser.
Reproduces how often:
Easily.
Brave version (chrome://version info)
Reproducible on current release:
Website problems only:
Additional Information
The text was updated successfully, but these errors were encountered: