Some Byte Range Requests are Returning Bad Bytes

VERIFIED FIXED in mozilla0.9.3

Status

()

P1
critical
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: lmcquarr, Assigned: dougt)

Tracking

Trunk
mozilla0.9.3
x86
Windows 2000
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pdt+], URL)

Attachments

(5 attachments)

(Reporter)

Description

17 years ago
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
(Reporter)

Updated

17 years ago
Depends on: 84332
Keywords: acrobat
(Reporter)

Comment 1

17 years ago
Created attachment 38160 [details]
This is the output from "cmp -l" comparing the two files
(Reporter)

Comment 2

17 years ago
Created attachment 38161 [details]
This is the modified Acrobat plug-in that writes the log file

Updated

17 years ago
Blocks: 85547

Updated

17 years ago
No longer blocks: 85547

Comment 3

17 years ago
This could also have to do with the overloaded OnDataAvail in
ns4xPluginStreamListener.
(Reporter)

Comment 4

17 years ago
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. 
(Reporter)

Comment 5

17 years ago
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
(Assignee)

Comment 6

17 years ago
av - taking this over.  
Assignee: av → dougt
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 7

17 years ago
Just verified that http byte range is returning the expected ranges.  Diggin 
into the plugin code now...
Status: NEW → ASSIGNED

Updated

17 years ago
Whiteboard: [pdt+]
(Assignee)

Comment 8

17 years ago
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. 
(Assignee)

Comment 9

17 years ago
Created attachment 40649 [details] [diff] [review]
Patch comes closer, but no luck...
(Assignee)

Comment 10

17 years ago
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

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

(Assignee)

Comment 12

17 years ago
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.  
:-)
Depends on: 76892

Comment 13

17 years ago
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.

Updated

17 years ago
No longer depends on: 76892
(Assignee)

Comment 14

17 years ago
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?  
(Assignee)

Comment 15

17 years ago
Created attachment 40972 [details] [diff] [review]
Clearer patch.

Comment 16

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

Comment 17

17 years ago
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.
(Assignee)

Comment 18

17 years ago
Rick, Can you sr= this patch?

Updated

17 years ago
Blocks: 76892

Comment 19

17 years ago
sr=rpotts
(Reporter)

Comment 20

17 years ago
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!


(Assignee)

Comment 21

17 years ago
could you try 40649
(Assignee)

Comment 22

17 years ago
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.
(Assignee)

Comment 23

17 years ago
Created attachment 41292 [details] [diff] [review]
Fixes prepended EOL if ODA only hands us the header

Comment 24

17 years ago
r=valeski

Comment 25

17 years ago
sr=rpotts
(Assignee)

Comment 26

17 years ago
Great! everything is checked into branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 27

17 years ago
verified fixed on 070904 trunk and branch builds. I get no page load errors with 
backgrnd loading turned off. dougt fixed everything !!!!!
Status: RESOLVED → VERIFIED
(Reporter)

Comment 28

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


You need to log in before you can comment on or make changes to this bug.