Calendar printing not working when 'Download PDF files instead of automatically opening them in Chrome' is enabled
Reported by
dduehn...@wbsd-schools.org,
Aug 30
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Enable the 'Download PDF files instead of automatically opening them in Chrome' 2. Attempt to print from Google Calendar 3. Print Preview appears, click 'Print', dialogue disappears and printing doesn't happen What is the expected behavior? Expect to see the printer selection dialogue box What went wrong? The 'Print Preview' page appears, but after clicking 'Print', the dialogue disappears and the document is not printed. Did this work before? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: 30.0.0.154 This appears to have been reported as far back as December of 2017 with several suggested long work arounds, but this is not the solution to the problem (see https://productforums.google.com/forum/#!topic/calendar/KBaEwPlmWlY ). In our environment, we have to use a 3rd part PDF viewer as the Chrome viewer tends to skew our reports. As such, we have the Chrome viewer turned off via GPO. This needs to be fixed properly, without complex work-arounds and without being forced to use a different browser and without having to enable the Chrome PDF viewer.
,
Sep 3
Able to reproduce the issue on #60.0.3080.0,reported chrome version #68.0.3440.106 and latest chrome #70.0.3538.0 on Ubuntu 17.10, windows 7 and Mac OS 10.13.6 by following steps as per comment#0. Note : In chrome version #60.0.3080.0 on Windows 10, after clicking 'print' button (mentioned in comment#0 Step-3) the file gets download as pdf file, but it is not observed in chrome versions #68.0.3440.106, #69.0.3497.72, #70.0.3538.0. The behaviour is seen from old M-60 builds, this is a non-regression issue. Hence marking it as untraiged and requesting someone from dev team to look into the issue. Thanks.!
,
Sep 5
The behavior of downloading the file as a PDF rather than printing it goes back at least as far as Chrome 55, which was released at the end of 2016, before any of the reports. Also, as a clarification, the "Print Preview" referred to in (3) seems to refer to the Calendar Print Preview, not Chrome's Print Preview. Is the request here to go back to the behavior of old Chrome builds - i.e. downloading the document as a PDF automatically - or did Calendar previously open the Chrome Print Preview and print the document successfully the way it does with the "Download PDF files..." setting off?
,
Sep 5
I think it would be best to download the pdf rather than just ignore the print request. Seems kind of silly to me to just ignore it when the option to use Chrome's poorly designed pdf viewer is turned off.
,
Sep 5
The change in behavior from downloading the PDF to ignoring it bisects to https://chromium.googlesource.com/chromium/src/+log/32427f84360e52cc5c88a62a65edccbd1e77249a..12f54fe316c43d843e95949b2f8ac45f35cbd467, so cc-ing tommmycli@. Any idea what might be going on here? Also, when I tested here, I was able to get back to the old download PDF behavior in Chrome 69 by going to chrome://flags and setting the "Click to open embedded PDFs" flag to "Disabled". If that works for you, it could be another option for a workaround while we continue investigating.
,
Sep 5
Almost certainly a side effect of chrome://flags/#click-to-open-pdf. I'll investigate.
,
Sep 5
This occurs when the user uses the in-page gear icon to open the in-page menu and selects Print. Calendar then provides its own print formatting option dialog, and then seems to generate a PDF which is then opened in an invisible IFRAME, and then printed. When Chrome's internal PDF viewer is active, everything works as planned and Chrome's print-preview dialog is then opened. -- But when Chrome's internal PDF viewer is deactivated by the 'Download PDF files...' option, that's when things get interesting. In the old world before chrome://flags/#click-to-open-pdf was enabled, IFRAMEed PDFs would trigger a download. After chrome://flags/#click-to-open-pdf, we specifically don't download IFRAMEed PDFs anymore, and display a placeholder. In this case, the IFRAME is invisible, so the placeholder doesn't help very much. Moreover, the IFRAME placeholder uses an OBJECT tag, which in this case is impeded by a CSP directive: object-src 'none'. See [1]. I think the right solution is for Calendar folks to check if the PDF viewer is disabled via accessing the navigator.plugins feature in JavaScript, and skip the special PDF generating flow in that case. Or, explicitly download the PDF instead of using an invisible IFRAME. -- [1] Refused to load plugin data from 'https://calendar.google.com/calendar/printable?mode=WEEK&wkst=1&pred=20180909&src=dG9tbXljbGlAZ29vZ2xlLmNvbQ&src=Z29vZ2xlLmNvbV84NmV1ZzdvMDhicTFncWpuMDNuYmU1N2RuOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t&src=Z29vZ2xlLmNvbV9wa3F0dmN1NHNjYjdrMzVyMGE1dmpnN2JsMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t&src=Z29vZ2xlLmNvbV9hY2IyZDk0ZW1qcmtiMm1jcmxoNzJicXM1OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t&prsd=20180902&pjs=true&pgsz=letter&pfs=NORMAL&po=AUTO&rand=-4639234212987324993#' because it violates the following Content Security Policy directive: "object-src 'none'".
,
Sep 5
I've filed an internal bug to ask Calendar to change how this works. b/114120164
,
Sep 12
Any status update?
,
Sep 12
I'm still working with the Calendar folks as well as Chrome folks to find the right resolution. In general though: When the embedded PDF viewer is disabled by enabling 'Download PDF files instead of automatically opening them in Chrome', and the PDF is embedded in an IFRAME, we will not automatically download them anymore. Instead, it will require the user to click a button within the IFRAME to download the PDF. I understand this is causing a problem with Calendar's printing flow -- and I'm working to find a reasonable solution.
,
Sep 18
I am noticing this more and more on other websites as well now. For example, we're using Star testing via Renaissance learning and this brings up a button to click to download the PDF, however, when clicking the button, nothing downloads. There is another website that we use for Staff training that has the same thing. It shows the file name and a download button, but the button does not trigger the download. I should not have to re-enable the Chrome PDF viewer in order to download these pdf files. Nor should I have to set a flag to allow it.
,
Oct 1
This was brought forward as a bug a month ago, I have updated with other websites having similar issues, and still no change in status? What's the hold up here? We should not have to use the Chrome PDF viewer. It's very limited in features.
,
Oct 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ad61fb278ef03510d0e5e2070018a05adc34489c commit ad61fb278ef03510d0e5e2070018a05adc34489c Author: Tommy C. Li <tommycli@chromium.org> Date: Fri Oct 05 17:53:23 2018 Click to Open PDF: Put placeholder HTML in IFRAMEs directly Previously, when the user has a disabled PDF plugin (or no PDF plugin) and the website has an IFRAMEed PDF, when Click to Open PDF was enabled, we would inject a fake <object> tag into the IFRAME to force a PDF plugin placeholder to appear. This approach is problematic with CSP, as CSP may forbid OBJECT tags from loading in IFRAMEs. This CL instead injects the placeholder HTML directly into the IFRAME. In the IFRAME case, the button is now a plain link, which should allow the user to click it and download the PDF even if CSP forbids <object> tags or JavaScript. It still may trigger a CSP warning if IFRAME is prohibited from running JavaScript, but that only hurts keyboard-accessibility, and doesn't prevent the mainstream use case from working. This CL also prevents the <object> tag from auto-opening the PDF after download, which was probably a mistake, since that overrides the user configurable "Always open with system viewer" option. Bug: 887752, 879149 , 878871 Change-Id: I900c08331d2cfc96ea7cd1cd46ea594445b0920b Reviewed-on: https://chromium-review.googlesource.com/c/1246956 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Tommy Li <tommycli@chromium.org> Cr-Commit-Position: refs/heads/master@{#597192} [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/browser/download/chrome_download_manager_delegate.cc [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/browser/plugins/pdf_iframe_navigation_throttle.cc [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/browser/plugins/pdf_plugin_placeholder_observer.cc [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/common/BUILD.gn [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/common/DEPS [delete] https://crrev.com/d92a8619b6a7c29294823c7ccefcbb1d7b43912c/chrome/common/pdf_uma.cc [add] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/common/pdf_util.cc [rename] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/common/pdf_util.h [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/renderer/chrome_content_renderer_client.cc [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/renderer/plugins/pdf_plugin_placeholder.cc [modify] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/renderer/resources/plugins/pdf_plugin.html [add] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/test/data/pdf/pdf_embed_csp.html [add] https://crrev.com/ad61fb278ef03510d0e5e2070018a05adc34489c/chrome/test/data/pdf/pdf_iframe_csp.html
,
Oct 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2a68a0f0255d80a83b49e2709f30818418960f46 commit 2a68a0f0255d80a83b49e2709f30818418960f46 Author: Marijn Kruisselbrink <mek@chromium.org> Date: Fri Oct 05 21:43:19 2018 Revert "Click to Open PDF: Put placeholder HTML in IFRAMEs directly" This reverts commit ad61fb278ef03510d0e5e2070018a05adc34489c. Reason for revert: New PDFPluginDisabledTest.IframePdfPlaceholderWithCSP test is failing in https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Mac10.13%20Tests%20%28dbg%29/5617 Original change's description: > Click to Open PDF: Put placeholder HTML in IFRAMEs directly > > Previously, when the user has a disabled PDF plugin (or no PDF plugin) > and the website has an IFRAMEed PDF, when Click to Open PDF was enabled, > we would inject a fake <object> tag into the IFRAME to force a PDF > plugin placeholder to appear. > > This approach is problematic with CSP, as CSP may forbid OBJECT tags > from loading in IFRAMEs. > > This CL instead injects the placeholder HTML directly into the IFRAME. > > In the IFRAME case, the button is now a plain link, which should allow > the user to click it and download the PDF even if CSP forbids <object> > tags or JavaScript. > > It still may trigger a CSP warning if IFRAME is prohibited from running > JavaScript, but that only hurts keyboard-accessibility, and doesn't > prevent the mainstream use case from working. > > This CL also prevents the <object> tag from auto-opening the PDF after > download, which was probably a mistake, since that overrides the user > configurable "Always open with system viewer" option. > > Bug: 887752, 879149 , 878871 > Change-Id: I900c08331d2cfc96ea7cd1cd46ea594445b0920b > Reviewed-on: https://chromium-review.googlesource.com/c/1246956 > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > Reviewed-by: Lei Zhang <thestig@chromium.org> > Commit-Queue: Tommy Li <tommycli@chromium.org> > Cr-Commit-Position: refs/heads/master@{#597192} TBR=thestig@chromium.org,tommycli@chromium.org,jochen@chromium.org,mkwst@chromium.org Change-Id: I8a5554c0489ec76a4adb35ca93afef9c4354316e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 887752, 879149 , 878871 Reviewed-on: https://chromium-review.googlesource.com/c/1265826 Reviewed-by: Marijn Kruisselbrink <mek@chromium.org> Commit-Queue: Marijn Kruisselbrink <mek@chromium.org> Cr-Commit-Position: refs/heads/master@{#597315} [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/browser/download/chrome_download_manager_delegate.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/browser/plugins/pdf_iframe_navigation_throttle.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/browser/plugins/pdf_plugin_placeholder_observer.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/common/BUILD.gn [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/common/DEPS [add] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/common/pdf_uma.cc [rename] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/common/pdf_uma.h [delete] https://crrev.com/7dad1c4475b73eacba0029db21683bcda832f8c7/chrome/common/pdf_util.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/renderer/chrome_content_renderer_client.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/renderer/plugins/pdf_plugin_placeholder.cc [modify] https://crrev.com/2a68a0f0255d80a83b49e2709f30818418960f46/chrome/renderer/resources/plugins/pdf_plugin.html [delete] https://crrev.com/7dad1c4475b73eacba0029db21683bcda832f8c7/chrome/test/data/pdf/pdf_embed_csp.html [delete] https://crrev.com/7dad1c4475b73eacba0029db21683bcda832f8c7/chrome/test/data/pdf/pdf_iframe_csp.html
,
Oct 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/49eacb581082e7a2469b613ad329e5dd75904616 commit 49eacb581082e7a2469b613ad329e5dd75904616 Author: Tommy C. Li <tommycli@chromium.org> Date: Tue Oct 09 21:19:26 2018 Reland "Click to Open PDF: Put placeholder HTML in IFRAMEs directly" This is a reland of ad61fb278ef03510d0e5e2070018a05adc34489c Original change's description: > Click to Open PDF: Put placeholder HTML in IFRAMEs directly > > Previously, when the user has a disabled PDF plugin (or no PDF plugin) > and the website has an IFRAMEed PDF, when Click to Open PDF was enabled, > we would inject a fake <object> tag into the IFRAME to force a PDF > plugin placeholder to appear. > > This approach is problematic with CSP, as CSP may forbid OBJECT tags > from loading in IFRAMEs. > > This CL instead injects the placeholder HTML directly into the IFRAME. > > In the IFRAME case, the button is now a plain link, which should allow > the user to click it and download the PDF even if CSP forbids <object> > tags or JavaScript. > > It still may trigger a CSP warning if IFRAME is prohibited from running > JavaScript, but that only hurts keyboard-accessibility, and doesn't > prevent the mainstream use case from working. > > This CL also prevents the <object> tag from auto-opening the PDF after > download, which was probably a mistake, since that overrides the user > configurable "Always open with system viewer" option. > > Bug: 887752, 879149 , 878871 > Change-Id: I900c08331d2cfc96ea7cd1cd46ea594445b0920b > Reviewed-on: https://chromium-review.googlesource.com/c/1246956 > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > Reviewed-by: Lei Zhang <thestig@chromium.org> > Commit-Queue: Tommy Li <tommycli@chromium.org> > Cr-Commit-Position: refs/heads/master@{#597192} Bug: 887752, 879149 , 878871 Change-Id: I2778524eac784186b141d7caee3801af3863fd2e Reviewed-on: https://chromium-review.googlesource.com/c/1269442 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Tommy Li <tommycli@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#598083} [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/browser/download/chrome_download_manager_delegate.cc [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/browser/plugins/pdf_iframe_navigation_throttle.cc [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/browser/plugins/pdf_plugin_placeholder_observer.cc [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/common/BUILD.gn [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/common/DEPS [delete] https://crrev.com/47e1665f4f428d7c42ef2373f8e6a9ad8848a990/chrome/common/pdf_uma.cc [add] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/common/pdf_util.cc [rename] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/common/pdf_util.h [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/renderer/chrome_content_renderer_client.cc [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/renderer/plugins/pdf_plugin_placeholder.cc [modify] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/renderer/resources/plugins/pdf_plugin.html [add] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/test/data/pdf/pdf_embed_csp.html [add] https://crrev.com/49eacb581082e7a2469b613ad329e5dd75904616/chrome/test/data/pdf/pdf_iframe_csp.html
,
Oct 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f commit d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f Author: Findit <findit-for-me@appspot.gserviceaccount.com> Date: Wed Oct 10 06:26:18 2018 Revert "Reland "Click to Open PDF: Put placeholder HTML in IFRAMEs directly"" This reverts commit 49eacb581082e7a2469b613ad329e5dd75904616. Reason for revert: Findit (https://goo.gl/kROfz5) identified CL at revision 598083 as the culprit for flakes in the build cycles as shown on: https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vNDllYWNiNTgxMDgyZTdhMjQ2OWI2MTNhZDMyOWU1ZGQ3NTkwNDYxNgw Sample Failed Build: https://ci.chromium.org/buildbot/chromium.linux/linux-xenial-rel/4027 Sample Failed Step: network_service_browser_tests on Ubuntu-16.04 Sample Flaky Test: PDFPluginDisabledTest.EmbedPdfPlaceholderWithCSP Original change's description: > Reland "Click to Open PDF: Put placeholder HTML in IFRAMEs directly" > > This is a reland of ad61fb278ef03510d0e5e2070018a05adc34489c > > Original change's description: > > Click to Open PDF: Put placeholder HTML in IFRAMEs directly > > > > Previously, when the user has a disabled PDF plugin (or no PDF plugin) > > and the website has an IFRAMEed PDF, when Click to Open PDF was enabled, > > we would inject a fake <object> tag into the IFRAME to force a PDF > > plugin placeholder to appear. > > > > This approach is problematic with CSP, as CSP may forbid OBJECT tags > > from loading in IFRAMEs. > > > > This CL instead injects the placeholder HTML directly into the IFRAME. > > > > In the IFRAME case, the button is now a plain link, which should allow > > the user to click it and download the PDF even if CSP forbids <object> > > tags or JavaScript. > > > > It still may trigger a CSP warning if IFRAME is prohibited from running > > JavaScript, but that only hurts keyboard-accessibility, and doesn't > > prevent the mainstream use case from working. > > > > This CL also prevents the <object> tag from auto-opening the PDF after > > download, which was probably a mistake, since that overrides the user > > configurable "Always open with system viewer" option. > > > > Bug: 887752, 879149 , 878871 > > Change-Id: I900c08331d2cfc96ea7cd1cd46ea594445b0920b > > Reviewed-on: https://chromium-review.googlesource.com/c/1246956 > > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > > Reviewed-by: Lei Zhang <thestig@chromium.org> > > Commit-Queue: Tommy Li <tommycli@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#597192} > > Bug: 887752, 879149 , 878871 > Change-Id: I2778524eac784186b141d7caee3801af3863fd2e > Reviewed-on: https://chromium-review.googlesource.com/c/1269442 > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > Commit-Queue: Tommy Li <tommycli@chromium.org> > Commit-Queue: Lei Zhang <thestig@chromium.org> > Cr-Commit-Position: refs/heads/master@{#598083} Change-Id: Ic7554c10dea8131f70f9ff2d6dbb7202e49a142f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 887752, 879149 , 878871, 892818 Reviewed-on: https://chromium-review.googlesource.com/c/1271929 Cr-Commit-Position: refs/heads/master@{#598224} [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/browser/download/chrome_download_manager_delegate.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/browser/plugins/pdf_iframe_navigation_throttle.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/browser/plugins/pdf_plugin_placeholder_observer.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/common/BUILD.gn [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/common/DEPS [add] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/common/pdf_uma.cc [rename] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/common/pdf_uma.h [delete] https://crrev.com/c27ea6d66efa8d360b86092d746f804ee81b7c8f/chrome/common/pdf_util.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/renderer/chrome_content_renderer_client.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/renderer/plugins/pdf_plugin_placeholder.cc [modify] https://crrev.com/d7eb8b3b3348dd9a702831b443a00e8a61ac5b7f/chrome/renderer/resources/plugins/pdf_plugin.html [delete] https://crrev.com/c27ea6d66efa8d360b86092d746f804ee81b7c8f/chrome/test/data/pdf/pdf_embed_csp.html [delete] https://crrev.com/c27ea6d66efa8d360b86092d746f804ee81b7c8f/chrome/test/data/pdf/pdf_iframe_csp.html
,
Oct 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a commit ce661f8f18e8d2a20a0e8dbae259ad8912aa166a Author: Tommy C. Li <tommycli@chromium.org> Date: Wed Oct 10 23:33:02 2018 Reland "Reland "Click to Open PDF: Put placeholder HTML in IFRAMEs directly"" This is a reland of 49eacb581082e7a2469b613ad329e5dd75904616 Original change's description: > Reland "Click to Open PDF: Put placeholder HTML in IFRAMEs directly" > > This is a reland of ad61fb278ef03510d0e5e2070018a05adc34489c > > Original change's description: > > Click to Open PDF: Put placeholder HTML in IFRAMEs directly > > > > Previously, when the user has a disabled PDF plugin (or no PDF plugin) > > and the website has an IFRAMEed PDF, when Click to Open PDF was enabled, > > we would inject a fake <object> tag into the IFRAME to force a PDF > > plugin placeholder to appear. > > > > This approach is problematic with CSP, as CSP may forbid OBJECT tags > > from loading in IFRAMEs. > > > > This CL instead injects the placeholder HTML directly into the IFRAME. > > > > In the IFRAME case, the button is now a plain link, which should allow > > the user to click it and download the PDF even if CSP forbids <object> > > tags or JavaScript. > > > > It still may trigger a CSP warning if IFRAME is prohibited from running > > JavaScript, but that only hurts keyboard-accessibility, and doesn't > > prevent the mainstream use case from working. > > > > This CL also prevents the <object> tag from auto-opening the PDF after > > download, which was probably a mistake, since that overrides the user > > configurable "Always open with system viewer" option. > > > > Bug: 887752, 879149 , 878871 > > Change-Id: I900c08331d2cfc96ea7cd1cd46ea594445b0920b > > Reviewed-on: https://chromium-review.googlesource.com/c/1246956 > > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > > Reviewed-by: Lei Zhang <thestig@chromium.org> > > Commit-Queue: Tommy Li <tommycli@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#597192} > > Bug: 887752, 879149 , 878871 > Change-Id: I2778524eac784186b141d7caee3801af3863fd2e > Reviewed-on: https://chromium-review.googlesource.com/c/1269442 > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > Commit-Queue: Tommy Li <tommycli@chromium.org> > Commit-Queue: Lei Zhang <thestig@chromium.org> > Cr-Commit-Position: refs/heads/master@{#598083} TBR=jochen@chromium.org Bug: 887752, 879149 , 878871 Change-Id: I6e6053e32a5d8acbeb18a32ba067a885ce915fe2 Reviewed-on: https://chromium-review.googlesource.com/c/1273985 Commit-Queue: Tommy Li <tommycli@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#598570} [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/browser/download/chrome_download_manager_delegate.cc [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/browser/plugins/pdf_iframe_navigation_throttle.cc [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/browser/plugins/pdf_plugin_placeholder_observer.cc [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/common/BUILD.gn [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/common/DEPS [delete] https://crrev.com/5ea805f821e4922f5ae39e2ed214ef7d210f4a8e/chrome/common/pdf_uma.cc [add] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/common/pdf_util.cc [rename] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/common/pdf_util.h [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/renderer/chrome_content_renderer_client.cc [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/renderer/plugins/pdf_plugin_placeholder.cc [modify] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/renderer/resources/plugins/pdf_plugin.html [add] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/test/data/pdf/pdf_embed_csp.html [add] https://crrev.com/ce661f8f18e8d2a20a0e8dbae259ad8912aa166a/chrome/test/data/pdf/pdf_iframe_csp.html
,
Oct 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8eb4c77037ba65b78883c5fca2b40411fb8c055c commit 8eb4c77037ba65b78883c5fca2b40411fb8c055c Author: Tommy C. Li <tommycli@chromium.org> Date: Mon Oct 15 20:39:52 2018 Click to Open PDF: Add IFRAME CSP browsertest. This CL is a followup to: https://chromium-review.googlesource.com/c/chromium/src/+/1273985 It adds the IFRAME test case, which did not seem flaky. The EMBED test case is still in-progress to deflake. Bug: 887752, 879149 , 878871 Change-Id: Iee52d4314539b2d457812a220a42051caeb1bab0 Reviewed-on: https://chromium-review.googlesource.com/c/1281262 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Tommy Li <tommycli@chromium.org> Cr-Commit-Position: refs/heads/master@{#599738} [modify] https://crrev.com/8eb4c77037ba65b78883c5fca2b40411fb8c055c/chrome/browser/pdf/pdf_extension_test.cc
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fac0d44345c4f0a7fc8f4f1464e7e79e1cb0e284 commit fac0d44345c4f0a7fc8f4f1464e7e79e1cb0e284 Author: Tommy C. Li <tommycli@chromium.org> Date: Thu Nov 15 16:56:48 2018 Plugins: Move WaitForPluginPlaceholder to a PluginTestUtils support Previously, only PluginPowerSaverBrowserTest had access to the ability to await the placeholder to be ready. Now that we want to do this for a PDF placeholder browser test as well, move this functionality to a test support class. This is patch 1/3 for this objective. Bug: 887752, 879149 , 878871 Change-Id: Ib0bc70f21d25ec35874025c0952f7c42555fce5b Reviewed-on: https://chromium-review.googlesource.com/c/1335781 Commit-Queue: Tommy Li <tommycli@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#608399} [modify] https://crrev.com/fac0d44345c4f0a7fc8f4f1464e7e79e1cb0e284/chrome/browser/BUILD.gn [modify] https://crrev.com/fac0d44345c4f0a7fc8f4f1464e7e79e1cb0e284/chrome/browser/plugins/plugin_power_saver_browsertest.cc [add] https://crrev.com/fac0d44345c4f0a7fc8f4f1464e7e79e1cb0e284/chrome/browser/plugins/plugin_test_utils.cc [add] https://crrev.com/fac0d44345c4f0a7fc8f4f1464e7e79e1cb0e284/chrome/browser/plugins/plugin_test_utils.h
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d89b22434f718dd0f82833b5a38ebc92444a99ea commit d89b22434f718dd0f82833b5a38ebc92444a99ea Author: Tommy C. Li <tommycli@chromium.org> Date: Thu Nov 15 16:57:52 2018 Plugins: Move NotifyPlaceholderReadyForTestingCallback to base class Move the LoadablePluginPlaceholder::DidFinishIconRepositionForTestingCallback method to the PluginPlaceholderBase base class so that the PDFPluginPlaceholder can also use it. This is a followup to: https://chromium-review.googlesource.com/c/chromium/src/+/1335781 This is patch 2/3 for this objective. Bug: 887752, 879149 , 878871 Change-Id: I14f2205d0d8d7c5fcd14fc2eac84e2b7fd1d52dc Reviewed-on: https://chromium-review.googlesource.com/c/1335997 Commit-Queue: Tommy Li <tommycli@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#608401} [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/chrome/renderer/plugins/chrome_plugin_placeholder.cc [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/chrome/renderer/plugins/pdf_plugin_placeholder.cc [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/chrome/renderer/resources/plugins/blocked_plugin.html [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/chrome/renderer/resources/plugins/pdf_plugin.html [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/chrome/renderer/resources/plugins/plugin_poster.html [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/chrome/renderer/resources/plugins/prefer_html_plugin.html [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/components/plugins/renderer/loadable_plugin_placeholder.cc [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/components/plugins/renderer/loadable_plugin_placeholder.h [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/components/plugins/renderer/plugin_placeholder.cc [modify] https://crrev.com/d89b22434f718dd0f82833b5a38ebc92444a99ea/components/plugins/renderer/plugin_placeholder.h
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c886c53eae3a8378502c4e185e29bfa709d4b97 commit 1c886c53eae3a8378502c4e185e29bfa709d4b97 Author: Tommy C. Li <tommycli@chromium.org> Date: Thu Nov 15 17:13:03 2018 Click to Open PDF: Add EMBED browsertest This re-adds the previously approved and committed browsertest, but this time with a fix for the flakiness. The body of the test remains the same, but with an extra call to: PluginTestUtils::WaitForPlaceholderReady(GetActiveWebContents(), "pdf_embed"); There is also an update the command line flags and an extra include. This is patch 3/3 for this objective. Bug: 887752, 879149 , 878871 Change-Id: Ie8c70d68fb3e3ebf9e70e5d9f2f1aa2f37b190f4 Reviewed-on: https://chromium-review.googlesource.com/c/1336086 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Tommy Li <tommycli@chromium.org> Cr-Commit-Position: refs/heads/master@{#608411} [modify] https://crrev.com/1c886c53eae3a8378502c4e185e29bfa709d4b97/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/1c886c53eae3a8378502c4e185e29bfa709d4b97/chrome/test/data/pdf/pdf_embed_csp.html
,
Dec 25
How about the progress of this issue ? My customer who has the same issue wants to know　Which version is likely to fix this bug.
,
Jan 7
This is still in the Calendar team's bug queue, but I don't have an ETA on it. From the Chromium perspective, it's working as intended now, although I sympathize that it must be frustrating. My suggestion is to use the Print command from the three dot menu on the Chrome toolbar rather than the internal Print command from the webpage.
,
Jan 7
+mshibahara: I've also updated the internal bug linked at b/114120164. I've followed up with Calendar team again there and have cc'ed you. I still think we can and should fix the user experience for our customers here.
,
Jan 7
I agree - it should be fixed so that we can use it the way we need to. I submitted this bug back in August! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by viswa.karala@chromium.org
, Aug 30