Closed Bug 644431 Opened 13 years ago Closed 13 years ago

Adobe PDF Files Larger than 5 MB Won't Load in Browser

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 7
defect
Not set
major

Tracking

(blocking2.0 Macaw+, status2.0 .1-fixed)

VERIFIED FIXED
Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed

People

(Reporter: cab26715, Assigned: jimm)

References

()

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

I cannot get any PDF files larger than 5 MB in size to load inside the browser.

On the above website (BP Deepwater Reports), the current Firefox tab hangs with a blank white screen on:
1) DNV Report EP030842 for BOEMRE Volume I.pdf (9.84 MB)
2) Sun Sperry Data (10.43 MB)

I can still access the other opened tabs.  However, Adobe PDF program never loads with these "large" files inside the browser.

Reproducible: Always

Actual Results:  
Browser tab displays a blank white page with large PDF files, even after waiting for a couple minutes.  NOTE - I have a 20 Mbps Comcast cable connection.

Expected Results:  
PDF file should be displayed (first page) and start downloading in seconds, like with Internet Explorer 9.
Sorry.....this information might be helpful as well.....

I am using Adobe Reader 10.0.1
Version: unspecified → Trunk
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110323 Firefox/4.2a1pre

Confirmed. The pdf file does not open, but displays an error message "The file is damaged and could not be repaired". Works fine in 3.6.x versions.
(In reply to comment #2)
> Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110323 Firefox/4.2a1pre
> 
> Confirmed. The pdf file does not open, but displays an error message "The file
> is damaged and could not be repaired". Works fine in 3.6.x versions.

That error message doesn't always appear.  I only saw the dialog ONCE out of about ten times trying to open these two files.  Since these files open in 3.6.x with the same Adobe PDF version, I am betting the Firefox code has an error somewhere.
Chris, would you be able to find the regression range using this tool please:
http://harthur.github.com/mozregression/

Marking new per comment 2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #4)
> Chris, would you be able to find the regression range using this tool please:
> http://harthur.github.com/mozregression/
> 
> Marking new per comment 2.

I will have to get back to you later on this, as I don't have enough time now before I have to leave.
I tried to use the Mozilla Regression tool, but can't find a good build going as far back as January 20th Nightly build.  I tried to install Debug builds earlier than that time period, but keep getting installation errors, such as "Oxc0150002".  I am going to see if 3.6.x has the problem now.
Candidate Build 3.6.16 from (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.16-candidates/build1/win32/es-ES/) works fine.

I accidentally installed the Spanish version instead of English, but don't think the language pack matters for this bug.
Regression Range : 
works:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100907 Firefox/4.0b6pre
broken:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre
pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cf0088ff07f2&tochange=36f5cf6b2d42
I'd more likely suspect Byron Milligan — Bug 588507: Skip caching if Content-Length is greater than eviction size. r=michal, a=betaN+

This code: http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginStreamListenerPeer.cpp#884 may be getting confused because this channel starts out with a cache file, but then it gets removed out from under the code later?
Uh, yes.  If we're caching as file we need to not evict that!
Blocks: 588507
In particular, note bug 81640 comment 16.
Attached patch Possible fix (obsolete) — Splinter Review
Can someone who has an Adobe plug-in and can hence reproduce the bug test whether this helps?
And we might need this in a bugfix update, if any...
blocking2.0: --- → ?
status2.0: --- → ?
(In reply to comment #13)
> Created attachment 521899 [details] [diff] [review]
> Possible fix
> 
> Can someone who has an Adobe plug-in and can hence reproduce the bug test
> whether this helps?

Boris:

I would apply the patch, but have two problems in doing so:

1) Don't know how to "install" the Possible Fix
2) I am now having problems with the Adobe PDF plug-in and [@ RtlpCallQueryRegistryRoutine].  See bug 645057.
> 1) Don't know how to "install" the Possible Fix

You need to compile from source to do that.

If someone here is currently able to reproduce but doesn't compile, let me know what OS you're on and I'll spin up a tryserver build.
I can reproduce this bug and I don't compile. I'm on Windows 7.

Might be useful to post a link to a guide(s) on how to test patches that are on Mozilla's Bugzilla (If it exists).
(In reply to comment #17)
> Might be useful to post a link to a guide(s) on how to test patches that are on
> Mozilla's Bugzilla (If it exists).

https://developer.mozilla.org/En/Simple_Firefox_build 
:-)
I can repo this, gimmie a sec..
I am currently in Mozilla Build program and had to also install Visual C++ 2008 Express to download the change set.  It is still downloading and is on "adding manifests".
That didn't seem to fix it. STR I'm using:

1) open the bug link
2) click on the DNV Report EP030842 for BOEMRE Volume I.pdf (9.8mb)

that opens a new window, and about half way through the load I get the error dialog.

I applied to patch and did a full build to be sure.
Jim, does backing out the bug 588507 patches locally fix this for you?
(In reply to comment #21)
> That didn't seem to fix it. STR I'm using:
> 
> 1) open the bug link
> 2) click on the DNV Report EP030842 for BOEMRE Volume I.pdf (9.8mb)
> 
> that opens a new window, and about half way through the load I get the error
> dialog.
> 
> I applied to patch and did a full build to be sure.

Thanks for testing the patch, Jim!  I tried using the steps on (https://developer.mozilla.org/En/Simple_build), but got "C compiler couldn't compile the file" or something like that.
I'm seeing this problem using the Foxit Reader too.
Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Foxit Reader 4.3.1.218
npFoxitReaderPlugin.dll 2.0.0.1102
I'm seeing this problem too under Firefox 4 under Windows, where it was working ok with 3 - had users report it with Adobe Reader installed and I've also seen it myself with Foxit Reader as well.
Attached file http log
(In reply to comment #22)
> Jim, does backing out the bug 588507 patches locally fix this for you?

Backing those out didn't seem to help. There doesn't appear to be anything useful in the log as well.
http://hg.mozilla.org/mozilla-central/rev/8a1dd2ad86b5

This is in the same range, I can try taking it out as well.
Oh, duh!  That dropped the kMaxDataFileSize from 65MB to 5MB!

So the real issue is that the patches in bug 81640 simply ignored bug 81640 comment 16....  <sigh>.
Blocks: 81640
..confirming, that fixed the problem.
Attached patch fix v.1Splinter Review
Attachment #521899 - Attachment is obsolete: true
Attachment #524308 - Flags: review?(bzbarsky)
Comment on attachment 524308 [details] [diff] [review]
fix v.1

r=me.  Jim, thanks for hunting this down!
Attachment #524308 - Flags: review?(bzbarsky) → review+
Assignee: nobody → jmathies
Depends on: 648429
Depends on: 648605
Landed on cedar:

   http://hg.mozilla.org/projects/cedar/rev/ab290352e316

Took out erroneous dependencies (wrong bug!)
No longer depends on: 648429, 648605
Pushed http://hg.mozilla.org/mozilla-central/rev/ab290352e316
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #34)
> Pushed http://hg.mozilla.org/mozilla-central/rev/ab290352e316

Confirmed fixed in the latest nightly.
Status: RESOLVED → VERIFIED
Note that this fix is not "correct", but is sufficient for most people. If you have a 65MB PDF this might show up again. There is an inherent race condition in the stream sequence because of async delivery that will only show up in practice in cases where we remove the cache file immediately after we think it is no longer in use. I'm going to fix this in another bug which I cannot find right now.
blocking2.0: ? → Macaw+
Comment on attachment 524308 [details] [diff] [review]
fix v.1

Approved for the mozilla2.0 repository, a=dveditz for release-drivers
Attachment #524308 - Flags: approval2.0+
(In reply to comment #37)
> Comment on attachment 524308 [details] [diff] [review]
> fix v.1
> 
> Approved for the mozilla2.0 repository, a=dveditz for release-drivers

http://hg.mozilla.org/releases/mozilla-2.0/rev/ff4efbda1b47
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: