The issue was happening with ADP, Wells Fargo and US Bank. Downloading the PDF to a file and opening worked just fine. It was just the embedded Reader in IE that seemed to be affected. Toggling compatibility mode also allowed the PDF to be viewed, but that is not a fix.

As to the idea that there is a small number of users affected, I think that Adobe is wrong on that one. Many people do their homework first to see if there are any glaring issues, so many probably have held back on this. Others may have installed it but don't use the embedded Reader. Then there are others still who don't open PDF files from HTTPS / SSL websites. I get that it has to be recompiled, but this version will NOT be widely used with this bug. Fix it and the others that have been discovered and release it as 10.1.3 before the "quarterly" update as 10.1.2 is useless in many peoples eyes.

We are back on 10.1.1 until this issue is resolved. Hopefully the security issues or other bugs don't bite us in the meantime while we wait.

I have a client who is experiencing the same issue with their web application, which presents PDFs (sent over SSL, not gzipped) within the browser. Upon upgrading to 10.1.2, their users are seeing grey screens (like the one shown in caseattle's screenshot) instead of the PDF document. The bug occurs regardless of the document being printed.

I'm able to get things back up and running on 10.1.2 by adding a Content-Length header when sending the PDF.

They were also experiencing what seems to be an unrelated 10.1.2 bug - when attempting to print directly from the browser, Acrobat Reader was crashing. This can be worked around by turning off Protected Mode.

I'm shocked to hear that a fix has been developed but is being pushed to the next quarterly release. These are fairly significant issues for web application vendors, and advising clients to downgrade to an older and less secure version of Adobe Reader is certainly not a solution that inspires confidence in Adobe.

Having possibility to set content-lenght for the http reposnse is great when I am using for example pure servlets where I can do this easily. But what about if I have simple static HTML pages where I am able to reproduce this problem? I described my simple case here: http://forums.adobe.com/thread/959677?tstart=0

Given the number of users that are experiencing this issue and the news that Adobe have a fix "ready", the usual way to deal with such things is to offer an *unsupported* pre-release version of the fix in English only. Several of the corporations here will doubtless prefer to have the option to do their own in-house testing before offering it out to their customers/users, but that could represent far less work than the grief they are having now with customers/users complaining that critical aspects of their service are now unusable.

The annoying thing is that we have seen the same (or apparently the same) issue in a previous version of the Reader plug-in for IE. Hence, I always read the release notes for the updates as I am very wary of any upgrade to the plug-in.

The frustrating thing I find is that the Adobe Updater virtually never gives detail on what it really wants to update, just that there is a download available that includes security etc fixes that are recommended for all users.

Please remember, Adobe, that we have paid for the full Acrobat product, in our case part of the CS5.5 Suite. Suggestions to downgrade to a previous Reader *do not work* as e.g. 10.1.1 will not install on top of a full Acrobat 10.1.2 installation, complaining that there is already newer software in place. I could only get back to an old Reader by following the procedure I described above on 24th Jan. The fact that Adobe has not apparently given any formal guidance on this issue at all and seems to have misunderstood the characteristics of the problem, is very worrying. Given that a similar issue has been seen before (where we _were_ able to install an older Reader on top of our full Acrobat), it suggests Adobe's test procedures do not include PDF displays via the plug-in over SSL, or at least not enough such situations to give any of us confidence that this problem will not appear again and we will all have more problems and complaining customers/users.

At least an unsupported fix would give us all the option to roll it out or not and would improve Adobe's PR profile, which is currently not looking at all good.

Good News: I have been PM'd by an Adobe person with a link to a downloadable English-only patch that hopefully fixes this issue. I have replied to say I haven't got time to re-install the newer Acrobat and try this fix for some time so it may be helpful if more people watching this thread make themselves known and thereby give Adobe the chance to offer this download to you, too.

I don't know quite why Adobe don't just post a link in this thread, but maybe they are concerned about it getting too much exposure too fast.

Either way, if you make yourselves known, you may get a PM and the option to try something that may fix your problem.

The more the merrier, I think.

Thanks to Adobe for responding ...he says, in advance of finding out if it works ;-)

We have thousands of new remote customers going live this month who rely on this pdf view aspect of our service and we cannot insist on them using chrome or firefox.

We have raised a case with Adobe support

Case #0182998569

No feedback from support to date, several follow-up calls, resisted Adobe's support staff attempts to lay this issue at IE 9's door.

Very keen to test the patch if an Adobe employer share this with us?

Our own investigations also seem to point to headers (removing them gave us a solution that worked temporarily/for some users) and gzip are the probable cause but we have been unable to get to the bottom of it.

Just received a patch from adobe below. This worked for us. Requested release date but no reply to date.

Hi,

Adobe has come out with a fix for the issue wherein the PDF is not being rendered properly when viewed through a browser, post updating to Reader 10.1.2. Since, the fix is in testing stages, could you please apply the same on a single system (Since, this for Testing Puposes only, do not deploy this across your network) and let me know if it fixes the issue at your end. You can download the EXE from: https://acrobat.com/#d=5c-aA12ca6hSO4TKZ4mbyQ

The steps to apply the fix are as below:

Log in to your computer as an Administrator.

Download the file using the above link.

Unzip the file to extract the executable AdobeAcrobatReaderPatch10.1.2_cpsid_93026.exe.

Do one of the following to run the application:

a. Double-click the EXE file.

b. Run the EXE file in silent mode by specifying the -silent flag on the command line. Open the command prompt ‘As Administrator’ to avoid UAC prompt dialog.

Example: <path to exe> -silent

5. Once the process is completed, you receive a prompt stating the result of the operation. You can choose to restart the system (if prompted) at that momemt or later, but a restart would be needed to ensure that the fix has been applied correctly.

6. A log is created in the temp directory (%temp%) with the name AcroPatchApplication1012.log.

Tom_5696, I attempted to contact Citibank IT Tech support in Sydney and Citibank Queen Street Brisbane today (over the phone and in person, respectively) to try and discuss the circumstances of their issue and compare notes, IT Manager to IT Manager, but they politely advised they are not experiencing Adobe 10.1.2 and IE issues. I even showed them a copy of this forum posting, but it was dismissed. They did acknowledge issues with Safari and Adobe Reader.

Our 10.1.2 form loading issues occur intermittenly: sometimes everything works, other times the form gets stuck loading 107kb/0kb (or similar) and a grey screen. It happens in only our production environment, but not in our pre-production environment. Both use https. We've done system and application traces and had sent them to our vendor who are looking for a configuration issue.

The recent patch appears to resolve the issue, but I am still looking for confirmation elsewhere from an organisation such as Citibank. I am allowing our vendor to continue to trawl through the traces to try and determine why it does not happen elsewhere in our systems.

I can confirm that Adobe's patch fixed the issue for my client's affected users.

I initially ran into the same issue where the problem was occurring in the production environment but not on our development boxes. I don't think Adobe has acknowledged this, but based on extensive testing on my end, the problem seems to occur specifically when a PDF is streamed over HTTPS without a Content-Length header. It turns out that the reason it wasn't working for me in production was that I had my web server's gzip middleware running, and when it gzipped the response, it stripped out the Content-Length header without replacing it. Maybe that's the issue you're running into?

With the IT system provided by our institution we had a similar problem. The connection is over the http protocol, a gray screen appeared only in IE (7 - 9), in Firefox (3.5 - 10) there was no problem.

I am very surprised to trivialize the matter by the support of Adobe. 01/18/2012 we assumed official notification, but so far there is no useful response. I don't understand why Adobe claims that the problem affects a small number of users.Only in our IT system, the problem was affected about 5,000 external user; as they are external we can't apply the proposed hot-fix.

Therefore, ignoring us by Adobe, we solved the problem in our application in a call to the servlet by adding the "contentLength" to the response header. Below is code fragment from our servlet:

We were having this problem as well. We have several sites that returned PDFs via HTTPS. Many of our users were fine but those with XP would just get a blank page returned. Our sites that return via plain HTTP were fine however. One of our developers narrowed it down to the cache settings in the content header being different on HTTP vs. HTTPS. The HTTP versions were getting cache settings of "Private" while the HTTPS versions were defaulting to "NoCache".

Fortunately, we already had a wapper service between our web sites and the SAS intrnet server that is generating the PDFs. He added the following lines to that wrapper and it solved the problem.

Response.CachControl="Private"

Response.AddHeader "Pragma", "Private"

The "Pragma" if a MS specific header which might explain why this appears to only effect IE.

not sure if it is applicable in the thread, but running reader 8.2 i was having the same issue. I played around with preferences for a while and finally succeded to get the document to display by checking off "show large image" in <Preferences - Page Display - under panel labeled "Page Content and Information">

I have a online web program. The browser use Adobe reader to open a PDF. In ths PDF, it has a link to point a file that store in Server. When click this link to open the file, the link file can open, but the original PDF screen will turn to grey. I need to press F5 to reload the original PDF.

The verion of Reader 9, it does not have this problem. Reader X or XI have this problem.

I already try to set the parameters on "Preference" of the reader , but it is useless.