New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 4076 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Nov 2008
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

acrobat plugin can't display some PDFs

Reported by boricsa...@gmail.com, Nov 4 2008

Issue description

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).


 
acrobat_plugin_error_1.png
146 KB View Download
AcrobatReader_error_message_2.png
7.3 KB View Download
AcrobatReader_error_message_1.png
7.3 KB View Download

Comment 1 by bksen...@gmail.com, 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.
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.

Comment 3 by Deleted ...@, 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
Labels: -Area-Misc Area-WebKit Plugins v-154.9 Replicable
Status: Untriaged
Loading it firsttime has to download the pdf and a black screen is shown while Chrome 
does that. For me the browser hung initially.
Status: Started
Status: Fixed
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


Status: Started
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://users.rcn.com/thomst/@inet029.html


Labels: Mstone-1.0
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.

Comment 9 by brian@chromium.org, Nov 10 2008

Labels: -Mstone-1.0 Mstone-1.1
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).
The PDF issue with a proxy server can be reproduced with the following URL:
http://www.lrei.org/caleven/ba2008/BA2008-catalog_web.pdf
Status: Fixed
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
Status: Verified
Verified in the official build Chrome: V - 154.22
Project Member

Comment 13 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 14 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 15 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment