Closed Bug 558397 Opened 12 years ago Closed 12 years ago
Some PDF Files doesn't open
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.3a5pre) Gecko/20100409 Minefield/3.7a5pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.3a5pre) Gecko/20100409 Minefield/3.7a5pre (.NET CLR 3.5.30729) I have some pages where i can never open PDFs. Its not only on microship sites. I see only a blank pdf page and the acrobat progress bar, which shows the download status 340kb from 345kb loaded. In my windows tmp folder i can see the downloaded .tmp file. I have the locked file unlocked and copied. The size of the File is exactly 2000kb. The original size of the file is 345KB. I can open the corrupted 2000kb file in fx manually and also in acrobat reader without problems. I have asked some people on mozillazine daily build thread to test the link and some of them have also problems. You can it read here: http://forums.mozillazine.org/viewtopic.php?f=23&t=1840625&start=15 Reproducible: Always Steps to Reproduce: 1.http://ww1.microchip.com/downloads/en/DeviceDoc/21712B.pdf 2.With my main profile it opens never. 3.With a clean new createt profile it opens sometimes. But mostly not. Actual Results: Blank PDF Page Adobe reader Progressbar shows 340KB of 344KB After some seconds, reports adobe a error. By reading of the document is a problem occurred(14). (translate from german) Expected Results: Complete downloaded and opened PDF. - tested with clean Profile without extensions - tested with disabled OOPP - IE has no Problems with this PDF
>IE has no Problems with this PDF But IE doesn't use the same plugin. The acrobat Reader NPAPI Plugin is using http range requests and a buggy server can break the pdf in such cases. Have you already tried to disable the plugin and open an external Acrobat Reader window instead ?
I have disabled the pdf plugin in addon manager. Download works and acrobat open it. The file size in the tmp folder is also correct. Plugin Version is 22.214.171.124. IE and Fx use the same nppdf32.dll as pdf plugin. Fx use the npapi plugin additionally? Maybe there is the problem. Then i see a lot of buggy servers. I see it not only at microchip sites.
Its not only on trunk also with new Namaroka 3.6.4pre i have the same problem. My last Namaroka build was 20100217 and working fine.
Namaroka has the pdf problem since 20100408, 20100704 working fine. dom.ipc.plugins.enabled;false
>IE and Fx use the same nppdf32.dll as pdf plugin. No, IE doesn't use npapi Plugins since IE5 or IE6. IE needs ActiveX Plugins. The np in NPpdf32.dll stand for Netscape Plugin.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
TheRave, can you perhaps narrow down to a one-day range when the problem appeared? If you can, I'd be interested in the changeset ID (the http:// url) from about:buildconfig for the last working build and the first broken build.
At the moment only for Namaroka: working: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a2ab794bfff4 not working: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/183798d66e35
On Trunk: good 20100308 http://hg.mozilla.org/mozilla-central/rev/afc7c1521284 Bad 20100309 http://hg.mozilla.org/mozilla-central/rev/dcfcfca09b45
The branch range is the Lorentz landing. The trunk range has a likely culprit, given that Acroread uses the cache-as-file stuff: bug 548217.
Yeah, probably. I'll look at this first-thing Monday. What exact version of Acrobat Reader are you using? Beltzner, this needs to block.
Assignee: nobody → benjamin
Priority: -- → P1
Acrobat Version 126.96.36.199.
We don't want to ship this regression to customers, but please be aware that code freeze is scheduled for TODAY (Monday, April 12 2010) @ 11:59 pm PST.
De-CRLF and with the missing test file.
a=LegNeato for 188.8.131.52
added missing file: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/bd772012c148
Verified fixed for 1.9.2 by passing mochitests. I cannot get the site mentioned in comment 0 to fail to give me a pdf on a clean machine.
The pdf viewing works now. Thanks for the fix.
Shouldn't this not be marked as verified as a whole since no one has checked it on trunk?
TheRave seems to have verified it. I checked using an hourly build, I think, also.
Yes. I have it tested on trunk & namaroka.
You need to log in before you can comment on or make changes to this bug.