New issue
Advanced search Search tips

Issue 653120 link

Starred by 2 users
Status: WontFix
Owner:
pastarmovj@chromium.org
Closed: Oct 2016
Cc:
asanka@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Blocking:
issue 628014



Sign in to add a comment

Resolve PDF download behavior in the presence of the AlwaysOpenPdfExternally policy

Project Member Reported by pastarmovj@chromium.org, Oct 5 2016 
https://codereview.chromium.org/2369353002/diff/150001/chrome/browser/plugins/plugin_prefs.cc#newcode236
chrome/browser/plugins/plugin_prefs.cc:236: return POLICY_DISABLED;
On 2016/10/04 at 10:06:34, pastarmovj wrote:
> On 2016/09/30 14:34:53, asanka wrote:

This should propagate up to PluginService::GetPluginInfo(), correct?
I.e. if always_open_pdf_externally_ is true, then the PDF plugin would
appear to all callers of GetPluginInfo() as disabled?

If so, as far as the downloads code is concerned, the behavior should be equivalent to disabling the PDF plugin. Is this not the case?

Once the PDF plugin is disabled, the downloads code should automatically
treat it as a regular download. The determination of whether a PDF
should be opened in the browser takes into consideration whether there
is a sandboxed plugin available to open the MIME type
(https://cs.chromium.org/chromium/src/chrome/browser/download/download_target_determiner.cc?rcl=1475652159&l=461).

Is this not sufficient? Are there issues with how PDFs are handled when
the plugin is disabled via 'aways open PDF externally' in addition to
not triggering the auto-open logic?

Comment 1 by pastarmovj@chromium.org, Oct 6 2016 

I re-read the questions again and I think what you are saying is exactly what this CL achieves.

It is correct that the always_open_pdf_externally_ will cause the GetPluginInfo calls to return that the plugin is disabled. Which it turn causes the download logic to treat the PDF as a regular download regardless of the auto-open logic which I am touching in the CL you reviewed.

What I was doing there is to make pdf downloads get automatically opened if this pref is set. 

I don't think there are any other issues in this case and we achieve the wanted behavior of pdf opening in Acrobat or whatever the user has. There is only one edge case I am going to handle in a separate CL - if Chrome is the default PDF app and you choose this option it ends up in an endless loop of pdf downloads being opened in Chrome only to be downloaded again and opened in chrome (this is not a new issue btw, I just got aware of it while testing my new policy).

Comment 2 by asanka@chromium.org, Oct 6 2016

Status: WontFix (was: Assigned)
Got it. Let's close this issue then. Thanks for looking into it.

I'm assuming that the policy is explicit about the auto-open behavior. Otherwise I'd rather avoid hardcoding the auto open behavior and allow the user to mark PDFs using the "Open always" setting.
►

Sign in to add a comment