85529 - Some Byte Range Requests are Returning Bad Bytes

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[lmcquarr]

In doing extensive testing of the byte range request support in mozilla,
I ran across some cases where Acrobat had an error, usually when drawing
the page.  I immediately suspected that some bytes returned to us
by Mozilla for the byte range were incorrect.  Since I have been
down this road before with another browser (Mac IE), I knew this
was going to be hard to track down.  

I ended up making a modified
version of our Netscape plug-in that writes the bytes out that
mozilla hands the Acrobat plugin directly into a log file in the position where
they would be in the PDF file  (I am attaching a copy of this plug-in
to this bug).  With my modified Acrobat plug-in, I went to one extremely
reproduceable test case and "captured" in the log what mozilla is sending us
(log file name is dumpdata.txt and it is located in the same directory as
the mozilla executable).

I then ran cmp.exe and compared what mozilla hands us with the original
PDF. From the output of that (which I have attached to this bug), you
can see the bad bytes.  The output format of "cmp -l" is:

<byte number>  <byte in file 1> <byte in file 2>

(Ignore the lines that say the byte in file 2 is 0 -- these are bytes that
we never downloaded because we didn't need them.)

Here is a complete list of attachments to this bug:

nppdf32.dll -- my modified Acrobat plug-in
Wildtype.pdf -- the original PDF file
datadump.txt -- the bytes that mozilla gave us directly written to disk
cmpout  -- output from running "cmp -l "


Here is how to reproduce:  

1 - Install Acrobat 5 and disable background downloading  (Prefs, General,
Options, uncheck check box for background downloading).

2 - Go to the above URL.

3 - After page 1 is drawn, go to page 2.  Usually, this will cause the
page drawing error.  If the page drawing error doesn't happen yet,
go to page 3.



This bug is dependent on 84332.  Once I apply the patch for that

Comment 1

[lmcquarr]

Attachment: This is the output from "cmp -l" comparing the two files

Comment 2

[lmcquarr]

Attachment: This is the modified Acrobat plug-in that writes the log file

Comment 3

[Peter Lubczynski]

This could also have to do with the overloaded OnDataAvail in
ns4xPluginStreamListener.

Comment 4

[lmcquarr]

Well, bugzilla refuses to create more attachments for me for this bug,
so when you are ready to work on this, I have the other pieces that
I promised (the output of my tool).  I also have some more cases
where I can repo the problem. 

Comment 5

[lmcquarr]

Here are a couple of more cases that produce page errors in Acrobat.
I have not gone to the trouble of running my tool to get
the extact bytes that are incorrect, but I can do that when whoever
is ready to work on it  (or we can save these as test cases
for making sure the fix is complete).

1 - Start Acrobat and turn on "continuous facing pages mode" (View
menu or button on bottom of Acrobat window).

2 - Disable background downloading (prefs, general, options, uncheck
"background downloading").

3 - Browse to any of the following URLs -- you will get page errors
or the pages just won't draw (usually five or six pages will draw
in the Acrobat window at a time for continuous facing pages mode).

http://access.adobe.com/browser/netscape/readtesting/Whamba.pdf
http://access.adobe.com/browser/netscape/readtesting/garden.pdf


http://access.adobe.com/net

Comment 6

[Doug Turner (:dougt)]

av - taking this over.  

Comment 7

[Doug Turner (:dougt)]

Just verified that http byte range is returning the expected ranges.  Diggin 
into the plugin code now...

Comment 8

[Doug Turner (:dougt)]

I have been working on this bug for the last two days.  I have 
made some progress.  In a nutshell, the multimixed converter has some serious 
problems dealing with data (not text) content and needs to reworked/rewritten.  
Unfortuately, there isn't enough time for this.  I think I have a patch that is 
closer, but until the multimixed converter is given alot of love, there will 
remain issues.

Patch still causes, but closer.  What did I break - I don't know. 

Comment 9

[Doug Turner (:dougt)]

Attachment: Patch comes closer, but no luck...

Comment 10

[Doug Turner (:dougt)]

What is wierd is that sometimes (all the time?) my compare log running with this 
patch looks okay, but I still get a warning.

Comment 11

[Peter Lubczynski]

This bug may be related to:
    * Bug 76892 loading of acrobat 5 pdf fails sometimes

Comment 12

[Doug Turner (:dougt)]

ahh... well, that sucks.  :-/

Marking dependent.  Ping me when you have a patch for 76892, or better yet, 
apply my patch and verify that it work for you when you have a fix for 76892.  
:-)

Comment 13

[Peter Lubczynski]

I'm not sure which bug goes first, this one or 76892. I think 76892 is more of a
general bug of Acrobat failing sometimes whereas this one actually has a good
testcase. I'll try some of the testcases in the other bug with the patch in here.

Comment 14

[Doug Turner (:dougt)]

Ok, the patch 40649 to necko produces exactly the expected bytes.  However, 
Acrobat still complains that the file is busted.  I think that the patch is the 
right thing to do.  It basically correct linefeeds before we send any data.  
Rick, can you review this patch?  

Comment 15

[Doug Turner (:dougt)]

Attachment: Clearer patch.

Comment 16

[Judson Valeski]

r=valeski on the 07/02/01 17:06 patch

Comment 17

[Marek Z. Jeziorek]

Doug, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the first RTM
candidate. It would be good, if this could be resolved ASAP.

Comment 18

[Doug Turner (:dougt)]

Rick, Can you sr= this patch?

Comment 19

[rpotts (gone)]

sr=rpotts

Comment 20

[lmcquarr]

Doug:

Now that I have a workaround for the "failed to load bug" associated
with HTTP 1.0 (76892), I was able to try your second patch and test
out wild type.

I still get a page drawing error on page two.  Using my modified
plug-in that writes the log file, as well as the cmp tool,
I discovered two bad bytes:

Byte    Mozilla      Original File
----    --------     --------------
458753  45           33
458754  120          367

Somehow, we are still getting bad bytes. 

Unfortunately, I am about to leave for the day .. and until
July 11.  I hope my tools will help you proceed without me!

Comment 21

[Doug Turner (:dougt)]

could you try 40649

Comment 22

[Doug Turner (:dougt)]

Patch checked into branch and trunk.

There still may be a problem with prepended EOL chars if the first ODA does not 
have enough data to work with.  This could be the cause of some problems 
reported in 76892.

Comment 23

[Doug Turner (:dougt)]

Attachment: Fixes prepended EOL if ODA only hands us the header

Comment 24

[Judson Valeski]

r=valeski

Comment 25

[rpotts (gone)]

sr=rpotts

Comment 26

[Doug Turner (:dougt)]

Great! everything is checked into branch and trunk.

Comment 27

[shrirang khanzode]

verified fixed on 070904 trunk and branch builds. I get no page load errors with 
backgrnd loading turned off. dougt fixed everything !!!!!

Comment 28

[lmcquarr]

Hooray!  Yahoo!  My QA God (Jeff Moran) and I will now take another wack
at testing.