New issue
Advanced search Search tips

Issue 705979 link

Starred by 6 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

PDF auto-open on download flipped when using the content setting to switch off internal viewer.

Project Member Reported by pastarmovj@chromium.org, Mar 28 2017

Issue description

It is possible that the auto-open bit is being flipped (or have been flipped in the initial version of the the code for some users) when the internal viewer is switched off.

We need to investigate and if needed correct the current behavior possibly flipping the bit if we can somehow guess if it was flipped due to this issue.

Bug https://bugs.chromium.org/p/chromium/issues/detail?id=680202 has some context in comments #25 onwards.
 

Comment 1 by notabi...@gmail.com, Mar 29 2017

Chromium Version 57.0.2987.110 (64-bit): PDFs are not opened with default pdf reader (Open PDF Files In Default PDF Viewer Application is checked) they are just downloaded to disk with no further actions. With "Open PDF Files In Default PDF Viewer Application" unchecked, they are correctly opened within the chrome viewer.

Windows 7 x64

P.S. same behaviour in Chromium 59.x
Re #1: This is currently the intended behavior unless you check the automatically open this file type (from the download bar right of the filename). It used to open them automatically but we considered this to be rather intrusive.

Comment 3 by notabi...@gmail.com, Mar 29 2017

"automatically open this file type" did the job. Thanks for your tip!

Comment 4 by sniper...@gmail.com, Apr 10 2017

I can confirm this is still an issue. Just did the following for a user:
Had issues with English PDF document language displaying in Greek, when viewed with Chrome 54 PDF viewer.
1. User was on Chrome 54
2. Disabled Chrome PDF Viewer via the chrome://plugins page
3. Tested same link to the document and it came up fine in Adobe Reader after the file was saved to local machine
4. Checked same document link on my system, Chrome PDF viewer worked fine, document was in English
5. Checked my version, which was 57
6. Uninstalled Chrome 54 from user's machine
7. Reinstalled new Chrome 57 from Google's website
8. Used document link and it still downloaded the document and it did not come up on Chrome Viewer
9. Went to Content Settings and unchecked "Open PDF Files in the default PDF viewer application"
10. Closed Chrome and reopened it
11. Went to same document link, link STILL downloaded and didn't open in Chrome Viewer
12. Validated Content Settings and option appears to have rechecked itself
13. Unchecked setting again and closed Chrome
14. Open Chrome and looked at the Content Setting again
15. Rechecked itself. WILL NOT UNCHECK!!!

Whatever the previous Chrome version's setting was for the Chrome PDF Viewer, becomes a permanent setting in the newly installed Chrome 57.

Comment 5 Deleted

Status: Started (was: Available)
Looking into this. I have a suspect about the reason.
Status: Fixed (was: Started)
https://codereview.chromium.org/2841843002/ Fix landed.

Cr-Commit-Position: refs/heads/master@{#467285}
Committed: https://chromium.googlesource.com/chromium/src/+/e08ac360faf4df6fc67b419d549ad682f8e56962

Comment 8 by dhw@chromium.org, Apr 26 2017

Labels: M-60
This is M-60 correct?  Adding that label for now.  Will this be merged back?
Yes, I will check with the PMs if this should be merged back. 
Possibly to M59 but I will take care of putting the right labels for that. Thanks!
Labels: Merge-Request-59
Requesting merge to 59. For https://codereview.chromium.org/2841843002/

(I don't know why the commitbot didn't post the landed CL on the bug)
Please tag with applicable OSs.  Thanks!
Project Member

Comment 12 by sheriffbot@chromium.org, Apr 28 2017

Labels: -Merge-Request-59 Hotlist-Merge-Approved Merge-Approved-59
Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
Project Member

Comment 14 by bugdroid1@chromium.org, Apr 28 2017

Labels: -merge-approved-59 merge-merged-3071
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/df3bb192e93b863cde928dd9416976180bfb24ae

commit df3bb192e93b863cde928dd9416976180bfb24ae
Author: Julian Pastarmov <pastarmovj@chromium.org>
Date: Fri Apr 28 07:49:27 2017

Remove the enable flag from all plugins after the option has been ported.

https://codereview.chromium.org/2518493002 removed the code to reenable
plugins but this doesn't reset the state and end up overwriting the
new pdf/flash setting each time the old prefs are read again.

After the CL the flag was not added to new Preferences files this code
only applies to existing legacy settings.

BUG= 705979 

Review-Url: https://codereview.chromium.org/2841843002
Cr-Commit-Position: refs/heads/master@{#467285}
(cherry picked from commit e08ac360faf4df6fc67b419d549ad682f8e56962)

Review-Url: https://codereview.chromium.org/2851703002 .
Cr-Commit-Position: refs/branch-heads/3071@{#286}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/df3bb192e93b863cde928dd9416976180bfb24ae/chrome/browser/plugins/plugin_prefs.cc

Sign in to add a comment