Sorry, the URL with an example PDF was broken. The full URL is:
http://www.karlin.mff.cuni.cz/~motl/entan-interpret.pdf

Chrome 3.0.195.27

Same issue. Opening any PDF link in the same tab, or opening it in a new tab, both 
result in a white screen. However opening it in a new window works.

This is a new issue following the release of Adobe Acrobat Reader 9.2

Paul

Unfortunately, it seems that in the newest Dev version, 4.0.222.12, the problem got 
more severe because the (1) shift/click solution explained above no longer works. 
Still, you can (2) open PDF in external windows.

I'm using Chrome 3.0.195.27 and even the "new window" trick doesn't work.  I have to 
right-click, then "Save Link As..", then open the download. 

After resize the window you can see the PDF content.
Adobe 9.2
Google Chrome 3.0.195.27

Resizing the window does not work for me.

In fact the Adobe plugin is effectively loaded (as seen in the Javascript console), 
and it effectively runs in the background (you'll see that in the process explorer). 
The plugin effectively downloads the PDF (in its own local cache). The plugin 
correctly sets the mouse cursor. However it fails to display its rendering within the 
window provided by Chrome.

It looks like if the window area offered by Chrome is clipped off (most prably by an 
event that is normally used to clear the window background and invalidate the 
window's client area and to which Chrome should reply by sending a refresh event to 
the plugin), and Adobe Reader can't render anything in that area, or if it renders 
it, it's within an empty area.

The only way that works to display the PDF for me is to open the PDF in its own tab, 
then close Chrome completely, and reopening it, so that the previously tabs that were 
open will be restored with its content. But any further attempts to close the tab and 
reopen it to display a new PDF will continue to fail.

Pressing F5 when the Adobe plugin should be displayed in the window just clears the 
window background to dark gray.

So something is wrong in the display model or architecture for plugins in Chrome (in 
fast I have observed that it also affects some other plugins based on the Mozilla 
plugin architecture, like Adobe Reader itself). It looks like that the Adobe Reader 
9.2 plugin was updated for Firefox, possibly to implement a more strict security 
mechanism (with better isolation from the rest of the web page), but this does not 
work within the HTML <embed> element that Chrome uses internally to render the 
plugin). May be Chrome does not properly sets the container's element size, and Adobe 
Reader thinks that the container area is empty or fully invisible, or Adobe Reader 
first checks that the element itself is within a visible window, with the standard 
decorations, to make sure that no site will attempt to emulate a Windows alert by 
displaying it in an unframed window. Or may be Adobe reader no longer accepts to 
render in an element of a HTML page that is not the root element of the document, or 
whose parent window is not a visible window (this is the trick that Chrome uses to 
render things offscreen within separate processes that communicate with the browser 
by transfering the graphics to the browser's GUI process). May be Adobe also rejects 
the attempt made by Chrome to copy the rendered content of the invisible area to 
another process like the Chrome's GUI process.

There are various things to check. But the "solutions" currently proposed by Google 
do not work: uninstalling both Chrome and Adobe Reader then reinstalling Chrome and 
then Adobe Reader (last update 9.2) does not work.

Note that in my experience, it affects ALL the PDF documents opened from a web link. 
For example the PDFs found in the Unicode.org's web site (like characters charts), 
which I am sure that they are completely valid and safe, and that do not contain any 
active component. This affects as well the PDFs that are generated from Wikipedia 
articles. In fact you can go at any website that features PDF contents, the same 
problem occurs.
It has worked for me in all past versions Chrome, and with all past updates of Adobe 
Reader. This has stopped to work only after Adobe Reader was updated into version 9.2 
(by Adobe Reader itself using its built-in update: I should have not accepted it, but 
I could not predict this misbehavior.

Now I cannot revert to an older version of Adobe Reader 9.1, as it is no longer 
available (and if Adobe has updated from 9.1 to 9.2, it said that it was a security 
fix, that we and Google should not ignore).

Resizing, whether it be in the current tab, a new tab or a new window, works for me.

Resizing works for me, too. 

Instead of finding the exact boundary of the window, a more convenient method to 
resize - and to force the PDF file to appear - is to double-click the upper "chrome" 
bar (transparent in Vista) which makes the toggle on/off for the full screen mode. 
Already after the first double-click anywhere at the top, you may see the PDF. But 
you may double-click for the second time to return to the original mode. (Of course, 
F11 instead of the double-click works, too.)

This problem should therefore be easy to fix in Chrome. If the Chromium programmers 
are too slow, someone outside the team could also create a Chrome extension that 
would apply the resizing steps artificially whenever it sees a new PDF anywhere. ;-)

Tested Today (Just Installed  Chrome), Oct 25
Chrome Version : v3.0.195.27
URLs (tested)  : http://www.nvidia.com/object/winxp_191.07_whql.html

Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: n/a -Not Installed--Not Tested
  Firefox 3.x: OK
         IE 7: n/a -Not Installed--Not Tested
         IE 8: OK

Confirmed it is happening when try to directly open in same or new tab.  \
Shift-open (New Window) does work.

I can confirm this bug with Chrome 3 and latest adobe reader (9.2). I don't understand 
why is still unconfirmed bug. In my opition this is a very severe problem.

Just made a major break throu on this issue.

I currently have latest dev of chrome (4.0.222.12) installed on Windows 7 x64.

I also have Adobe Acrobat Pro 9.2 with all updates applied.

I have had the same as issue as everyone else. PDF files not showing in browser, I 
hit refresh and the background goes grey. But if I grab the tab and move it or resize 
it the PDF shows. This tells me that its not an opening issue, its more of a 
rendering issue.

Can anyone else confirm this please?

Dear Eangulus, the "resizing" fix for the missing PDF has been discussed by most 
commenters above. Everyone should try to read the existing observations before posting 
his would-be new insights. 

S. Malacarne: please be more patient: I don't think it's so urgent if this simple way 
to circumvent the problem exists. Another way to circumvent it is to set the Acrobat 
Reader to open PDF files outside the browser, see the solution "2" at the very top.

John, I'm not sure whether you're still the plugin owner, but this is nasty.  I believe 
it's a "Regression" in Acrobat Reader 9.2 rather than in Chrome, but the consequences 
are the same.  Can you triage?

whoa, this is pretty major.

Glen: can we work with people at Adobe to make sure they test with Chrome before auto-
updating?  I'll look into it tomorrow, unless anyone else beats me.

Adding correct Glenn.

 Issue 25416  has been merged into this issue.

Yes, please fix this issue.  Setting Acro Read to open pdf outside browser works for 
me.

r29805

When will this fix be pushed to stable release?

Jon, Mark, or Anthony will know.

 Issue 25524  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=29805 

------------------------------------------------------------------------
r29805 | jam@chromium.org | 2009-10-22 13:08:32 -0700 (Thu, 22 Oct 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/webplugin_delegate_impl_win.cc?r1=29805&r2=29804

Fix painting issue in Reader 9.2.

I don't know exactly what the cause of the bug is.  But through experimentation I found that the plugin starts painting after the second NPP_Setwindow call.


BUG=24883
Review URL: http://codereview.chromium.org/315013
------------------------------------------------------------------------

 Issue 15978  has been merged into this issue.

 Issue 25489  has been merged into this issue.

 Issue 25100  has been merged into this issue.

@Mark, @Anthony, @Jon - Do we know when this fix will make Stable? It's one of the
top issues in the user forum right now. 

Note: to give more information about this.  Firefox and Safari call NPP_SetWindow 
frequently, sometimes before every paint, even when the plugin geometry doesn't change. 
We only call it when things change.  It seems the latest version of Reader ignores the 
first NPP_SetWindow call (perhaps it has bogus values in Firefox or Safari?) and as a 
result they never register the size and paint until the user resizes the tab.  Opera 
has the same regression as well.

 Issue 25729  has been merged into this issue.

Any timeline on the final fix being made available with regression tests completed ?

 Issue 25786  has been merged into this issue.

 Issue 25759  has been merged into this issue.

 Issue 25739  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=30195 

------------------------------------------------------------------------
r30195 | laforge@chromium.org | 2009-10-27 08:47:48 -0700 (Tue, 27 Oct 2009) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/195/src/webkit/glue/plugins/webplugin_delegate_impl.cc?r1=30195&r2=30194

Fix painting issue in Reader 9.2. 

I don't know exactly what the cause of the bug is. But through experimentation I found that the plugin starts painting after the second NPP_Setwindow call. 


BUG=24883
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=29805

Review URL: http://codereview.chromium.org/337036
------------------------------------------------------------------------

 Issue 25922  has been merged into this issue.

 Issue 25882  has been merged into this issue.

 Issue 25919  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=30251 

------------------------------------------------------------------------
r30251 | jon@chromium.org | 2009-10-27 14:39:05 -0700 (Tue, 27 Oct 2009) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/223/src/webkit/glue/plugins/webplugin_delegate_impl_win.cc?r1=30251&r2=30250

Merge 29805 - Fix painting issue in Reader 9.2.

I don't know exactly what the cause of the bug is.  But through experimentation I found that the plugin starts painting after the second NPP_Setwindow call.


BUG=24883
Review URL: http://codereview.chromium.org/315013

TBR=jam@chromium.org
Review URL: http://codereview.chromium.org/337048
------------------------------------------------------------------------

 Issue 26244  has been merged into this issue.

The bug is now genuinely fixed in a Beta version 4.0.223.16, download it here:
http://motls.blogspot.com/2009/01/google-chrome-20.html

Test PDF:
http://www.karlin.mff.cuni.cz/~motl/entan-interpret.pdf

Verified in Chrome 3.0.195.32 (Official Build 30772).

 Issue 26684  has been merged into this issue.

 Issue 26423  has been merged into this issue.

 Issue 26105  has been merged into this issue.

Can anybody tell me how to display the next page in a multi page document on Mac? I 
do get the first page and then I can't do anything else.

Thanks!

 Issue 23409  has been merged into this issue.

Dear Weivsara, concerning the Apple Mac page-two problem, see  Issue 26460 . Perhaps, 
unfortunately, that issue was merged with a more general Mac PDF bug, Issue 13716.

 Issue 26403  has been merged into this issue.

In the newest Dev version 4.0.237.0, the PDF bug is also fixed. So the latest versions 
of Stable, Beta, as well as Dev editions have cured the regression.

Hi. I am running 4.0.237.0 and Adobe Reader 9.2 and today still cannot open a .pdf 
directly in the browser.

I have tried a number of .pdf links i.e. 
http://stlab.adobe.com/wiki/images/d/d3/Test.pdf
http://www.calstate.edu/SAS/ept.pdf

If I download the files to desktop they open in Adobe OK.

These links work fine in Opera 10.10 Beta and Firefox 3.6 Beta.

Same here, using "4.0.239.0 (Ubuntu build 31231)" (Chromium) under Karmic. 
Maybe the proposed fix did only work under Win/Mac? Would there be a way to use 
Evince/other Poppler-based PDF viewers instead?

Perhaps I should have mentioned that I am also a Linux user (Linux Mint 7). Built on 
Ubuntu Jaunty. I am using Chromium direct from the repo:  
http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/ jaunty main

Hi this morning  I tried a little experment.

Removed acrobat and chromium. This left Evince as the default .pdf viewer.
Started Firefox and selected a .pdf to open. The .pdf opened OK in Evince.
Installed Chromium 4.0.240.0 (Ubuntu build 31387). 
Started Chromium and selected a .pdf to open which opened OK in Evince.
Installed Acroread and selected the option to make it the default .pdf viewer.
Started Chromium and selected a .pdf to open. Just got blank screen in Chromium.
No amount of resizing, refreshing or selecting print would make the page display.
Removed Acroread and config files and reinstalled as "not" the default viewer and
restarted Chromium and still a blank screen is displayed when selecting a .pdf to view.
Removed Acroread completely and now .pdf's open in Evince.

I had hoped that a clean or non-default install would have helped but unfortunately
it was not to be.
 

kevinleighton61, andreas: This sounds like a generic plugin issue on linux, not like what 
this bug is about.

Kevin, could you file a new linux bug? Go to new.crbug.com, choose the linux template 
from the dropdown, shortly describe the problem and paste your great notes from 
comment 54. Then paste the number of the bug you filed in a comment to this bug.

Hi thakis

Thanks for your feedback.

This is now open as  issue 27097 .

For Windows, this problem appears to have been resolved.  My Chrome is version 
3.0.195.32 and this problem is no longer happening for me on Windows Vista.

 Issue 26936  has been merged into this issue.

 Issue 26807  has been merged into this issue.