Regression : ‘Couldn’t load Plugin’ window appears broken on PDF page.
Reported by
avsha...@etouch.net,
Feb 23 2018
|
|||||||
Issue descriptionChrome Version : 66.0.3353.0 (Official Build) 545e59b4d718e55d2fa80a0a6c104de9236a0eda-refs/heads/master@{#538677} 32/64-bit OS : Mac(10.12.6, 10.13.1, 10.13.4), Linux(14.04 LTS), Windows(7,8,8.1,10) Test URL : https://msu.edu/~urban/sme865/resources/embedded_pdf.html What steps will reproduce the problem? 1. Launch chrome, navigate to above URL, scroll down the page and click on ‘Print’ icon seen on the PDF toolbar. 2. Right click in Print preview window and select ‘Inspect’ option from context menu to open devtools. 3. Hit CMD + R to reload the devtools (chrome://print page opens) and click on browser’s ‘Back Arrow’ button. 4. Observe the ‘Couldn’t load Plugin’ message on PDF page. Actual Result : ‘Couldn’t load Plugin’ window appears broken on PDF page. Expected Result : ‘Couldn’t load Plugin’ window should render completely on PDF page. This is a regression issue broken in ‘M-66’ and providing the bisect using ‘per-revision’ script: Good build : 66.0.3350.0 (Revision : 537343) Bad build : 66.0.3352.0 (Revision : 538313) You are probably looking for a change made after 537416 (known good), but no later than 537417 (first known bad). Change Log URL: https://chromium.googlesource.com/chromium/src/+log/0c6506c1695d80b5867216722c8dde8f35a3c125..eca148ae891c734bc109476fc085af4c3b59205c Suspect : https://chromium.googlesource.com/chromium/src/+/eca148ae891c734bc109476fc085af4c3b59205c @sergeyu : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
,
Feb 26 2018
Not related to crrev.com/537417 (that change was for content_shell, it can't have any effect on chrome).
,
Feb 28 2018
tommycli@, Dan suggested that you might have some insight on this.
,
Feb 28 2018
Hey rharrison... since this occurs after the plugin is loaded and you are in print preview, I'm going to direct this bug to thestig and rbpotter.
,
Feb 28 2018
Just reproduced this on Linux on current Chrome Stable 64.0.3282.167 so this isn't an M66 regression. The vast majority of users also don't navigate to chrome://print via dev tools or otherwise, so reducing priority here. Interestingly, this also repros for me with any PDF and with manual navigation to chrome://print via the address bar. So a somewhat simpler repro is: (1) Open any pdf in chrome (e.g. https://www.irs.gov/pub/irs-prior/f1040ez--2017.pdf) (2) Click print icon or use Ctrl + P to bring up print preview. (3) Navigate to chrome://print with address bar (4) Go back - plugin is disabled.
,
Feb 28 2018
,
Mar 1 2018
ChromeContentRendererClient::CreatePlugin() is being called with plugin_info.status = PluginStatus::kDisabled at the end. That is set by the browser in PluginInfoHostImpl::Context::FindEnabledPlugin(). The value is calculated in ChromePluginServiceFilter::IsPluginAvailable() with "return use;" returning false. Something about navigating to chrome://print directly confused the renderer.
,
Mar 2 2018
,
Mar 6 2018
,
Mar 28 2018
The pdf-isolation feature did not help. Though the click-to-open-pdf feature, if active, does catch this and display a nicer UI from which one can open the PDF again in a new tab. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by avsha...@etouch.net
, Feb 23 2018