Chrome Version : 0.3.154.9 URLs (if applicable) : http://www.springerlink.com/content/8487277104807l04/fulltext.pdf Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 3: OK Firefox 3: OK IE 7: OK Chrome 0.2: OK What steps will reproduce the problem? 1. Use the URL above. Alternatively, go to springerlink.com, choose an article with Full Access (marked with a solid green rectangle) and click on the PDF icon/link (pointing to the PDF version of the fulltext article, a fulltext.pdf file). 2. 3. What is the expected result? Acrobat pugin should display the PDF file within the browser client area. What happens instead? First the browser client area grayed out, then it seems to be frozen for a while (shitching task/tab then refocusing on the fulltext.pdf tab, the client area shows the last displayed screen section of that area; see screenshot attached). After some (~4-5) minutes (!) (when I don't close the .pdf tab) the Acrobat Reader window comes up with an error message "A file I/O error has occured" or "The file is damaged and could not be repaired" (see attached screenshots). Please provide any additional information below. Attach a screenshot if possible. Sometimes while the client area is frozen (mostly when switching to the Acrobat Reader process) the AcroRd32.exe process takes the full CPU load and the whole Chrome freezes (I even can't switch to it) for some minutes. The Adobe Acrobat Plugin process (in Chrome's Task manager) produces no anomalous load in the meantime. There was no problem displaying these PDFs with any other browser, including an earlier version (0.2.149.30) of Chrome. Also no problem with any other PDFs I checked, they're displaying correctly in the browser. I could manage only once (after I killed the Adobe Acrobat plugin process) the PDF to be loaded correctly, but unfortunately I couldn't reproduce this... The Acrobat Reader versions (I checked) are 8.1.1 and 8.1.2. This issue is not related to any of the issues 3578 , 3647 , 3855 , 3977 ; I checked all of them, but those PDFs opened withot problem (and doesn't produced any error mentioned in the issue descriptions).
Nov 4 2008,
[Confirmed] in 0.3.154.9 (Official Build 4058) Additional info: But when I click the Refresh button repeatedly, the display alternates back and forth between displaying PDF properly and showing a black screen.
Nov 4 2008,
This Refresh-thing doesn't work for me... Any time I try to refresh, it simulates a new request, but then nothing, just blanks (grays out) the browser client area.
Nov 4 2008,
The same is happening for me. It only started happening in the last couple of days (coincides with 0.3.154.9?) Here's another PDF that won't load: www.standards.co.nz/NR/rdonlyres/0206C4B4-7E8E-4641-8E33- 57E4DDA26857/0/3604brochurefinalJULY2006.pdf
Nov 5 2008,
Loading it firsttime has to download the pdf and a black screen is shown while Chrome does that. For me the browser hung initially.
Nov 5 2008,
Nov 6 2008,
New Revision: 4842 Log: This fixes bug http://code.google.com/p/chromium/issues/detail?id=4076, which was a hang while loading certain PDF files. This was a regression caused by support for NPN_RequestRead (PDF Fast Webview). We had incorrectly assumed that the Content Type showing up for partial HTTP Responses would always end with the boundary. A content type can show up like multipart/byteranges; boundary=--bound--; charSet=utf8. As a result we would look for the wrong boundary in the actual data resulting in a hang. The parsing code now accounts for this. Added a unit test to test this case. Bug= 4076 R=jam Review URL: http://codereview.chromium.org/9198
Nov 8 2008,
PDF files which support PDF FastWebView don't load at times if there is a proxy in the way. This happens because the proxy at times downloads the document and serves byte ranges as requested by the client. It specifies quoted boundary strings, which is legit. The client is supposed to trim the quotes. We don't do that and thus reader just fails to load the file in chrome. http://email@example.com
Nov 9 2008,
This is fixed on the release branch with r5070. The fix will be released in 154.14 or later. I'll leave this open for Ananta to close when he lands the change on trunk.
Nov 10 2008,
If it's fixed on branch, I will remove the 1.0 label and push to 1.1 (so we don't get nasty divergences but we don't have to track for OOB).
Nov 10 2008,
The PDF issue with a proxy server can be reproduced with the following URL: http://www.lrei.org/caleven/ba2008/BA2008-catalog_web.pdf
Nov 10 2008,
New Revision: 5132 Log: This fixes another issue with PDF documents loaded via FastWebView (NPN_RequestRead). This would occur whenever Chrome was configured to use a proxy server. The NPN_RequestRead API sends out byte range requests to the server, which then responds with a HTTP Partial Response header (206) followed by a content type which specifies the boundary string which separates individual body parts. We parse out the boundary string in our plugin implementation and then send out individual body parts to the plugin. In this case the proxy server would respond to the byte range request and send back the response with a quoted boundary string. This is legit as per MIME specs. We did not handle this case and hence would look for the quoted boundary string in the data which did not exist. Fix is to trim the leading and trailing quotes in the boundary string. Added a unit test to handle this case. Bug=http://code.google.com/p/chromium/issues/detail?id=4076 R=jam
Nov 17 2008,
Verified in the official build Chrome: V - 154.22
Oct 12 2012, Project Member
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Mar 11 2013, Project Member
Apr 6 2013, Project Member
Sign in to add a comment