+ Tommy - can we get your thoughts on the recent change in PDF behavior here?

 Issue 845401  has been merged into this issue.

Raising to p1 and rbs since we now have multiple reports of impacted customers.

 Issue 845199  has been merged into this issue.

Hey all,

On the consumer side, our experts flagged this issue this morning. We don't have a ton of reports yet, but here are a few:

- https://productforums.google.com/forum/#!topic/chrome/TvdOwNlIBL0
- https://productforums.google.com/forum/#!topic/chrome/yBRFwxKhcWY
- https://productforums.google.com/forum/#!topic/chrome/bTyHUHWd40Y

One of the reports suggests this is happening on more sites than Gmail, and another suggests that the "Download PDF files instead of automatically opening them in Chrome" setting may be the culprit.

I also did a quick Listnr search and we're seeing the same type of reports there as well:

- https://listnr.corp.google.com/report/85459898079
- https://listnr.corp.google.com/report/85459892278
- https://listnr.corp.google.com/report/85459713263

Thanks!

Eng is rolling back this change in Chrome so the issue should resolve for most users in next few hours. We're working with Gmail team to understand how we can prevent this issue in the future also.

This breaks our internal web application where we use inline content disposition to produce PDF reports to an external PDF viewer.

#6: Thanks for confirming!

We also saw feedback reports for Mac as well, so adding that tag just for reference.

- https://listnr.corp.google.com/report/85459979837
- https://listnr.corp.google.com/report/85459808443
- https://listnr.corp.google.com/report/85459792968

grant@marathonpm.com: Can you link a test page we can use to verify that we are handling your PDF download flow correctly?

The rollback should be in place as of 1pm Eastern time / 6pm GMT. After that time, it may be necessary to restart Chrome / reboot device in order to pick up the change.

OK, if the 1pm fix doesn't work I will write a servlet which should produce a PDF and expose it via an external link. It is standard iText PDF generation though, as demonstrated here: https://stackoverflow.com/questions/40521687/how-to-open-a-new-pdf-file-in-a-new-browser-tab-with-itext-java

Just tested. Your 1pm roll-out has resolve our problem. Thank you !

Same here - this has helped with Gmail PDF attachments.  I haven't had a chance to try Sheets documents yet

grant@marathonpm.com: Can you describe further what the broken and expected behavior was for your use case?

1. Did you have "Download PDF files instead of automatically opening them in Chrome" on?
2. Did you have "Always open with system viewer" on?
3. Any enterprise policies active?

Thanks.

tommycli@chromium.org:

1. Yes.
2. No.
3. No.

Basically I would expect that the java servlet's output be processed in such a way as to download as a PDF file when "Always open with system viewer" is off. That is how it has always worked before and how it works with other browsers.

Thanks again for resolving the issue.

grant@marathonpm.com:

We recommend using:

  Content-disposition: attachment 

to trigger a download.

Currently Content-disposition: inline within an IFRAME triggers a download, but that's unintentional. Once we turn the feature back on, inline content disposition PDFs within IFRAMEs will no longer trigger a download.

tommycli@chromium.org:

Should the behavior not be to download no matter what if the user selects not to use the internal PDF viewer ? We have some users that do like to use the internal viewer for the PDFs that are relatively simple and don't have forms with javascript-calculated fields. The only reason we use external PDF viewers is because the internal one cannot perform those calculations.

I guess the other question then would be if it is possible to use the internal PDF viewer if Content-disposition is set to "attachment" ?

Hmm... based on what you said, you have a few options:

 1. You could make the IFRAME the inline PDF is loaded in larger. In that case, once the feature is turned on (chrome://flags/#click-to-open-pdf), the user would see a Placeholder (see attached image).

 2. The other thing you could do is look at the contents of navigator.plugins in JavaScript. You will get a different result depending on whether or not the user has that setting "Download PDF files.." on or not. #2 is not officially supported, but it's just a possibility as a stopgap.

 3. In either case, please test with chrome://flags/#click-to-open-pdf enabled, as that will be re-enabled by default soon.

Deleted: PDFPlaceholder.png 3.5 KB

	PDFPlaceholder.png 3.5 KB View Download

Deleted: navigatorplugins.png 92.2 KB

	navigatorplugins.png 92.2 KB View Download

Just as a data point for this conversation: We do currently NOT use IFRAMES, and the PDFs download correctly using Content-disposition: inline. We use standard JSF one one application and standard Java Servlets in another.  I suspect if that behavior suddenly changed you would have a lot adversely affected users with environments similar to ours.

Another noteworthy point is that we did see the placeholder in the version before the rollback, however, clicking on the "OPEN" button gave us the original JSF page, not the PDF itself.

A little more feedback on this. After some experimentation, I found that setting Content-disposition: attachment and chrome://settings/content/pdfDocuments disabled, then the PDF file does download and is shown at the bottom of the screen. If the user then clicks on that download it does open inside Chrome's internal PDF viewer.

if chrome://settings/content/pdfDocuments is enabled, then the file downloads but when the user clicks on it, it is rendered by the external viewer (PDF Studio in our case).

So, in conclusion this works for us, even though it is one more click for the user to see the report.

 Issue 845591  has been merged into this issue.

I reproduce this issue with Gmail, Yahoo (yahoo.co.jp) mail and Yahoo (yahoo.com) mail. Disabling chrome://settings/content/pdfDocuments, the issue won't happen. So I suspect this is Chrome issue, not Gmail.

Unable to reproduce the issue on mac 10.13.3 and Win-10 using chrome reported version #66.0.3359.181.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Turned on the following setting. 
chrome://settings/content/pdfDocuments 
2. Downloaded an attachment PDF file via the Gmail web UI. 
3. Observed that the pdf document downloaded without any issues.

The issue might be reproducible using corp account. Hence, forwarding the issue to inhouse team for further triaging of the issue.

Thanks...!!

Deleted: 845443.mp4 791 KB

	845443.mp4 791 KB View Download

After upgrading to Version 66.0.3359.181 (Official Build) (64-bit), I cannot reproduce this issue anymore. My OS is Linux. But my colleague can reproduce this issue with the same version in different OS (Windows 10).

THIS FIX SOLVED MY ISSUE

 chrome://flags/#click-to-open-pdf > disabled

We use iframes and on new update saw OPEN pdf place holder requiring another click step replace the iframe upseting our process flow - this may not be visible in non iframe processes but still be there or upset downloads automatically being initiated. 

if I enable the above it still totally replicates the issue we had straight after the update even if you have rolled back so that flag must have been new or enabled by default on latest update.

We have thousands of UK users of our cloud apps so the impact was pretty immediate at start of business Monday for those groups using chrome and allowing updates. They had to swop to IE temporary while we sought resolution to app flow being broken. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6c6905a98aef2b4bdee9590ec24f80655f2a01b2

commit 6c6905a98aef2b4bdee9590ec24f80655f2a01b2
Author: Tommy C. Li <tommycli@chromium.org>
Date: Wed May 23 17:16:18 2018

Click to Open PDF: Correctly handle Content-disposition: attachment.

Previously, the Click to Open PDF feature was not correctly handling
navigations with Content-disposition: attachment.

This CL brings its handling in line with the MUST download logic
already present in content/ and adds a test.

This should fix Gmail PDF attachment behavior.

Bug:  845443 
Change-Id: Ib4947c1ce18ce5fb1e7c84c2dd5852a60f5d4954
Reviewed-on: https://chromium-review.googlesource.com/1069309
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Commit-Queue: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561134}
[modify] https://crrev.com/6c6905a98aef2b4bdee9590ec24f80655f2a01b2/chrome/browser/plugins/pdf_iframe_navigation_throttle.cc
[modify] https://crrev.com/6c6905a98aef2b4bdee9590ec24f80655f2a01b2/chrome/browser/plugins/pdf_iframe_navigation_throttle_unittest.cc

Do you have ETA when the fix will be delivered to users?

+govind I see RBS label is already attached, but is this fix going to be merged to M67? We have at least 39 enterprise/education customers reporting this issue.

tommycli@:
how safe & critical is the change to merge to M67? 
Is the server side fix mention at #6 & #10 good enough? 
Pls note if approved and merged, this change will directly go to stable next week as today's M67 last beta already went out.

Re #33, This is M66 regression and M67 is going to stable soon so we can only take above merge in for M67 only if it is fully safe and fix is verified in canary.

No need to merge to 67. We've flipped the feature off for M67, and will be aiming to re-release this in M68 (with the fix included).

The NextAction date has arrived: 2018-05-25

Okay, this has been fixed for M67 by turning the feature off.

We have a fix in, and will re-launch the feature in M68. Gmail and Google Drive team have verified that attachments work with the fix in c#30.