Closed Bug 76892 Opened 24 years ago Closed 24 years ago

loading of acrobat 5 pdf fails sometimes

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: spamnet, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [PDT+][no eta])

Attachments

(2 files)

pdf file that is not loading correctly
(deleted), application/pdf
Details
Javasnooper logging proxy server tool
(deleted), application/octet-stream
Details 
seen with builds from 4/18

Acrobat 5 plugin fails sometimes to load a whole pdf. I only get the first page
(or a part of it, or more). 
When I go back and retry, it usually works. 
Haven't seen this with acrobat4

I have ethernet connection/university network, if that is of importance. The
files I tried yesterday were mostly from www.acm.org, but I had the same problem
with IBM. Usually larger files 500K and up
Keywords: acrobat
This is something important to investigate when bug 78741 gets fixed as Acrobat
5 is the current version shipping from Adobe.

Arun: Do you think if the PDF plugin version 5 works with Gecko, Adobe can be
evangelized to update their installer in the next spin of Acrobat 5.0?

Liz needs to be cc:ed after bug 78741 gets fixed as she may be able to provide
more insight.
Depends on: 78741
Confirming on 2001051720 Win2k with Acrobat 5.0.1 2001/03/27.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oliver,

Can you please attach the testcase you confirmed with? If too large for 
bugzilla, please link.

Thanks.
Assignee: av → peterlubczynski
http://www.svbus.com/KeyStoneUG.pdf

The file displays fine if loaded in the standalone Acrobat Reader.
URL: http://www.svbus.com/KeyStoneUG.pdf
Status: NEW → ASSIGNED
Keywords: nsbeta1
Priority: -- → P2
the test url does not load in my 4.x either...
Yes, it's failing for me.  w2k. Mozilla 0.9.
Btw, this also fails on Windows ME. For me it fails always, not just sometimes.
Currently using build 2001052904.
Works nicely after bug 82415 and bug 53363 get fixed. Try the patch in bug 
82415.
Depends on: 53363, 82415
I just checked in the patch that should make this now load and work just fine. 
Marking FIXED. If it doesn't please reopen.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This is still failing for me on Windows ME using build 2001053104. Is the patch
included in this build?
Confirming....reopening...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Here is a talkback ID from a crash opening a .pdf earlier today:
TB31146996Z

Also, now Mozilla will open some .pdf files but not others. As best I can tell,
it started opening some of them after I started up Acrobat manually to view a
local file and left it open.
Can someone kick the Talkback server and attach the stack to this bug? I keep 
getting this error:

Problem: 
                     An error has occurred while processing the expression:

                        vendorName=FCQuery.GetFormattedBlackBoxKey( bbid, 
"SVendor ID", "Plain text")

                     The error occurred on (or near) line 404 of the template 
file D:\Talkback\website\reports\incidenttemplate.cfm.

                        400: <cfset incidentState = 1>
                        401: <cfif incidentState NEQ 1>
                        402:         <CFLOCATION 
URL="emptyincident.cfm?bbid=#bbid#" ADDTOKEN="no">
                        403: </cfif>
                        404: 
                        405: <cfset vendorName=FCQuery.GetFormattedBlackBoxKey( 
bbid, "SVendor ID", "Plain text")>
                        406: <cfset vendorName=Trim(StripCR(vendorName))>
Status: REOPENED → ASSIGNED
Keywords: crash
Trigger Type:   Program Crash <http://climate/images/spacer.gif>   Trigger
Reason:   Access violation <http://climate/images/spacer.gif>
Thread ID:  <http://climate/images/spacer.gif> Call Stack:    (Signature =
KERNEL32.DLL + 0xa298 (0xbff6a298) c8e0ae99)
     KERNEL32.DLL + 0xa298 (0xbff6a298)  
     MSVCRT.DLL + 0x113d (0x7800113d)  
     MSVCRT.DLL + 0x1f5f (0x78001f5f)  
     _requestread
[d:\builds\seamonkey\mozilla\modules\plugin\nglsrc\ns4xPlugin.cpp, line 1084]
     NPPDF32.DLL + 0x4a53 (0x10004a53)  
     NPPDF32.DLL + 0x347c (0x1000347c)  
     NPPDF32.DLL + 0x31ce (0x100031ce)  
     NPPDF32.DLL + 0x4f2f (0x10004f2f)  
     NPPDF32.DLL + 0x4e56 (0x10004e56)  
     NPPDF32.DLL + 0x6331 (0x10006331)  
     KERNEL32.DLL + 0x3613 (0xbff63613)  
     0x01c4b260  
<http://climate/images/spacer.gif> Registers:
EAX: 01333830 EBX: 01eac46c ECX: 2d343230 EDX: 31363831
ESI: 01333c34 EDI: 01eac068 ESP: 0068f874 EBP: 0068f8a8
EIP: bff6a298 cf pf af zf sf of IF df nt RF vm   IOPL: 0

Well, a reboot and a day later and now things seem to be working for me. I am
still using the 2001053104 build, but now I seem to be able to open up all .pdf
files, including the one that caused the crash that I reported previously.
[d:\builds\seamonkey\mozilla\modules\plugin\nglsrc\ns4xPlugin.cpp, line 1084]
That crash happens in RequestRead which I just fixed recently.

Reporter: please bang on this some more because I really do think I fixed it 
but am not sure. Please note your findings in this bug....it works as expected 
or it crashes/fails to load. Thanks!
Whiteboard: [maybe working?]
peter: for future talkback queries, try this url : http://climate/main/qfa.cfm
Build: 2001060120
URL: 
http://rns.ericsson.se/Solutions/mps/prod_info/mps-g_3/documents/web-01_5542/155
10-CNH_160_230_Rev_F.PDF

Unfortunately, this is an internal Ericsson URL. The URL does not load, but some 
strange things happen when I go there. 
1) I was able to generate a crash with the following TB ID: TB31237504G 
2) When I go to the URL the page is just blank, but the Acrobat Reader Splash 
screen does come up showing that Acrobat is loading.
3) If I right click on the conent area I get the usual HTML popup menu, but it 
thinks that it is in a frame (ie it has "Open Frame in New Window" "Show Frame 
Source" etc)
4) If I select "Show Only This Frame" from the right click popup menu it takes 
me to chrome://navigator/content/navigator.xul and displays a Mozilla inside a 
Mozilla
5) My network connection goes wacky (ie my mp3's stop streaming and keep having 
to rebuffer after I access this page)

Okay, after playing around with it for a while, I figured out that it does the 
same thing if I tried to load the above PDF from my harddrive instead. I'll 
attach the offending PDF in a seperate comments.

  

  



    
    

    
  
Okay, the attachment displays correctly in Mozilla if you just click on it from 
the bugreport. *sigh*  However, if you save it to your hardrive and try to open 
it fails as I earlier indicated. Could it be a MIME type problem? When I 
uploaded the attachment I indicated application/pdf for the MIME type, perhaps 
the server I am trying to download from isn't setting the MIME type correctly...

  

  



    
    

    
  
*** Bug 83181 has been marked as a duplicate of this bug. ***

  

  



    
    

    
  
See bug 84160 about loading files locally. 

  

  


Depends on: 84160

    
    

    
  
Okay, so a bug has already been identified for loading files locally, but that
doesn't explain why the same file won't load from a web server.

  

  



    
    

    
  
*** Bug 85160 has been marked as a duplicate of this bug. ***

  

  



    
    

    
  
Got another failing testcase:

http://www.samsungusa.com/cmc_upload/product/brochure/170MP.pdf

I wanted to buy this monitor :(

  

  



    
    

    
  
Looks that this bug has been on and off. Point is, in mozilla 2001060703 ,
branch 0.9.1 , the bug persists.
When downloading a PDF file ( any file ) the Adobe plug in looks some activity
but it is not displayed - the acrobat reader-, and nothing appears in the window...
The file is not displayed, nor Acrobat.

  

  



    
    

    
  
another testcase:
Steps to Reproduce:
1. Go to http://access.adobe.com/browser/netscape/net6.pdf
2. Scroll down towards the bottom of the page near Appendix A.
3. Click on, "Complex2.pdf."
Result:
PDF file does not display in browser. Also, see notes. 

  

  



    
    

    
  
is this not going to be in 0.9.2 ? I see this bug all time on today's build 
...on NT...0621 trunk

  

  



    
    

    
  
The testcase above fails. It is a byte range stream. cc:ing Av, DougT, and Liz
if they are aware of this issue. I think the link clicking is a result of DDE, Liz?

  

  


Whiteboard: [maybe working?] → [byte-range]

    
    

    
  
nominating nsbranch

  

  


Keywords: nsbeta1 → nsBranch
Whiteboard: [byte-range]
Target Milestone: --- → mozilla0.9.2

    
    

    
  
This bug depends on bug 87397. With the patch in that bug, the svbus testcase
loads (after a long delay).

The Samsung one still doesn't load though. However, with the patch from bug
85334, this looks better.

If anyone has a free moment I need reviews in both those bugs to bake the
patches on the trunk.

  

  


Depends on: 87397

    
    

    
  
Hi Peter:


I downloaded today's build on TWO machines (NT and Win2k).
I even used the installer this time and not the zip file. I deleted
my mozilla profiles.   I drop in the nppdf32.dll plug-in and then browse
to PDF files.   Acrobat starts up, but the file comes up blank.


Once again, this has been happening now for over a week.
I will get into the debugger in our plug-in and tell you exactly what I see.
I will put the notes in the bug.


As far as I am concerned, the daily builds are still DOA for Acrobat
and have been for over a week.


Liz


  

  



    
    

    
  
First, I went to a clean lab machine, which had never seen Acrobat OR 
Mozilla and installed both (today's mozilla build from 4:00 a.m.).

Dropping the Acrobat plug-in into the mozilla plug-ins folder, and then
browsing to a PDF file, Acrobat does start, but the screen is blank.

So I got into the debugger with the Acrobat plug-in and now I can see
what is the problem.

The problem is at NPP_NewStream, mozilla is now passing Acrobat
a stream->end of 0, rather than the stream length.   This has been 
happening for a while, and has now been reproduced here at Adobe
on two Win2k machines (including a clean lab machine), one NT machine
and on the Mac.  

I have a local build that I did from June 7th from the tar ball that does not 
have this problem.  I believe it started a little over a week or so ago.



  

  



    
    

    
  
BUT, I have made a big discovery! 

The problem happens depending on the server.  When I go to PDFs
on www.adobe.com, for example, everything is fine.  When I go to PDFs on 
internal
servers, usually all apache, I see the problem.

Further, when I hook up my javasnooper tools to mozilla (implements a proxy
server that logs the HTTP conversation -- you point mozilla at is as your proxy
and then you point it at your real proxy), the above PDF files on www.adobe.com
that used to worked no longer work!

So now I have a way for you folks to hopefully repo this:  I will put my 
javasnooper
tool as an attachment onto the bug, along with instructions on how to set it up,
and VOILA!  You hopefully will now see the same problem we are seeing. 



  

  



    
    

    
  

      
      
      
      

        Attached file
          
        Javasnooper logging proxy server tool (deleted)
        — 
      

    


  

  

  



    
    

    
  
Here are the instructions for using the javasnooper tool:
Instructions on how to use.
1. run the .exe file and expand the folder.
2. Place the Javasnooper folder on you root drive (easier that way)
3. Delete any log.txt files in your javasnooper folder
4. Edit the "runserver.bat" file to point to your own internal proxy server
Runserver.bat currently reads:
jview SnoopServer -local 8080 -host http-relay -port 8080 -l log.txt

You want to modify the "-host http-relay" to be the name of your internal proxy
server, and the "-port 8080" to be the port that your proxy server is set
up to listen to (usually 8080). 
5. Open the web browser and navigate to the link you will click on to test the 
process.
6. From the Run line run c:\javasnooper\runserver.bat
7. Change your browser proxy settings from what they currently are to your CPU's 
machine name or to "127.0.0.1" -- which means the same machine as you are 
running on, at port 8080. 
8. Click on the link in your browser

NOTE: At this point, all of your HTTP traffic will first be routed locally
and logged to the "log.txt" file, and then forwarded to your internal
proxy server.





  

  



    
    

    
  
I want to make a few more observations that might be useful (or might not be!).

It is very interesting that viewing on PDF files on www.adobe.com work until
you run the javasnooper tool.  This tool has the side effect of changing
the timing characteristics of the transaction.  I have seen bugs with
other browsers (names omitted here :-) that were very timing dependent.
Is this bug timing dependent?  Peter says that he will ask Shrirang to
use YOUR internal tool for slowing down the network traffic to see
if you can repo the bug that way (since you don't have a proxy server ...
you can not use my tool).

Peter also hypothesized that using a proxy server may tickle the bug.
I will try the experiment of turning off my proxy and going directly
to internal files and see if the problem still happens.


  

  



    
    

    
  
Per my previous comments, I did the experiment of turning off any proxy
settings and connecting directly to the internet.  I tried the same
internal PDF files that failed, and they still failed.  This is not,
therefore, related to proxy settings.

Back to the timing hypothesis ... hopefully Shrirang can repo this
problem consistently using your own internal tools that slow down
network traffic.

BTW -- it doesn't seem to have anything to do with what server is hosting
the PDF (other than potentially the horse power of the box itself):

www.adobe.com works and it is Apache 1.3.19
Internal server dosai does not work and it is a Netscape 1.1 server (I can
just hear the groans now!)
access.adobe.com does not work and it is Apache 1.3.6

(Dosai and access.adobe.com are both fairly old machines -- so again
this points to timing characteristics as the possible culprit.)





  

  



    
    

    
  
One final experiment that I did:

On our internal server dosai, we have a script that lies and says
it can not do byte range requests.  When this script, therefore, is
used to get a PDF file, the entire PDF is downloaded before anything
is displayed.  

When I use the "No Bytes serving" script, I have no problems with the
PDF files on this server.  When I do not use this NOBS script,
I can not use PDF files on this server.

Example:

http://dosai/cgi-bin/nobs/starr.pdf  -- this works OK (entire file is 
downloaded)

http://dosai/starr.pdf  -- this does not work -- screen is blank because
mozilla tells our plug in that the stream->end  is 0.



  

  



    
    

    
  
OK -- I have a local build now of the latest tarball, and from there,
I can trace back into the mozilla code as to what is going on.

mozilla calls NPP_NewStream in our plug-in from 
ns4xPluginStreamListener::OnStartBinding(nsIPluginStreamInfo* pluginInfo)
(NS4xPluginInstance.cpp).

In that function, we get the stream length, which turns out to be -1. 
Later in the function, we set the length to 0:

// if we don't know the end of the stream, use 0 instead of -1. bug 59571
  if (mNPStream.end == -1)
    mNPStream.end = 0;

Next, I will try to figure out how come we don't know the end of the stream,
since the HTTP headers from the server very clearly say what the content
length is.



  

  



    
    

    
  
Continuing on my previous comments, and tracing back to see how it
is possible that this stream got a length of -1 (and was therefore
set to 0) ...

In nsPluginStreamListenerPeer::OnStartRequest(nsIRequest *request, nsISupports* 
aContext) (NSPluginHostImpl.cpp), there is a:

 rv = channel->GetContentLength(&length);
  // it's possible for the server to not send a Content-Length.  We should
  // still work in this case.
  if (NS_FAILED(rv)) {
    mPluginStreamInfo->SetLength(-1);   <--------------WE are Hitting this

  }
  else {
    mPluginStreamInfo->SetLength(length);
  }


The length is set to -1 because the call to GetContentLength failed.


Now, why did that call fail?  Next, I dug around in that code and here is
where it failed:

     nsDerivedSafe<T>*
      operator->() const
        {
          NS_PRECONDITION(mRawPtr != 0, "You can't dereference a NULL nsCOMPtr 
with operator->().");
          return get();
        }


(This is in NSComptr.h .)

Next, I will try to figure out why the nsComPtr we passed in null.



  

  



    
    

    
  
Liz,

We fail to get the content length from the channel when we call:
  rv = channel->GetContentLength(&length);

..in nsPluginHostImpl.cpp. This could possibly be a side-effect of the reload
bug. The reload bug causes your cache entries to become invalid so when you
(re)load, it tries to fetch the file from the cache. The cache we have the file,
and instead of going out to the net, the cached copy is delieverd. Only one
problem is that it's currupt and the file isn't there. So it's possible that's
why the length is zero, even if it's a network stream. See bug 87397.

However, since that's already checked in to the trunk and you can reproudce with
your tool, it could be something else. Take a look at the |channel| in the debugger.

  

  



    
    

    
  
I just got two crashing bugs in our service pack assigned to me, so I 
am afraid that I am derailed from working on this for a bit.


  I have a way for you to repo it without my javasnooper tool!
Silly me!  The files on access.adobe.com will repo the problem,
and that is an external server.

Try this one:

http://access.adobe.com./browser/cookbook.pdf


This should repo the problem for you ... let me know ASAP.


  

  



    
    

    
  
on my regulat conenction speed...it loaded this url  
http://access.adobe.com./browser/cookbook.pdf  
after a very long time..and then doing anything froze my browser. I have another 
bug open for the freeze. going to try the slower connection thing....


  

  



    
  
Whiteboard: [PDT+]

    
    

    
  
peter, i tried tever's directions and used the 28.8 connection with our proxy..
things are damn slow..but acrobat works definitely for me..I tried the 
access.adobe.com test pages and they load in acrobat reader as a plugin. But 
some pages do not load (for the records). windows NT 062803 trunk

  

  



    
    

    
  
Yes, works great for me too, in fact even in last week's build along with
today's. In fact, in the debug build I even see each chunk called through
RequestRead for the Cookbook and then slowly pops on the screen using our 28.8
kbs proxy. 

I'm now going to try Liz's Javasnooper and see what's going on as we're not
seeing what you're seeing.

BTW, perhaps it's Acrobat version specific? I keep getting this nag to update my
Acrobat. I appear to be running 5.0.0.327.

Oh, one more thing, just to rule out the cache, could you "clear" it the Prefs
dialog, under Advanced. about:cache also may reveal what's in there before you
clear it.

  

  



    
    

    
  
And the "cookbook" testcase on your server does indeed work using your
Javasnooper tool connecting to our 56k proxy. Something is really strange here.

  

  



    
    

    
  
pushing out. 0.9.2 is done. (querying for this string will get you the list of
the 0.9.2 bugs I moved to 0.9.3)

  

  


Target Milestone: mozilla0.9.2 → mozilla0.9.3

    
    

    
  
This bug may be related to:
* Bug 85529 Some Byte Range Requests are Returning Bad Bytes


  

  



    
  
Blocks: 85529

    
    

    
  
wait.. which way.

Can you disable seekablity, and verify that this bug goes away?

  

  



    
    

    
  
Actually, that's the wierd thing. The Samsung testcase seems to request a SEEK
stream but the nsIRequest didn't seem to be a BRR. It's takeing the non-seekable
ODA path.

I think the dependancy should be the other way around.

  

  


No longer blocks: 85529

    
    

    
  
Peter, Ben, 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.

  

  



    
    

    
  
I have some new data:

1 - I went to a clean machine in the lab, installed acrobat and the 4:00 am 7/2 
build
of mozilla.

2 - I started mozilla and made a new profile (did not convert existing 4.X 
profile).

3 - Without setting a proxy server, I browsed various PDF files -- and they
worked fine  (did not get the blank page).

4 - As soon as I turned on the Adobe corporate proxy server  (used by
everyone in the company to get out to the Internet), I started seeing
the problem again.

5 - Did steps 3 and 4 over several times.

Conclusion:  The problem I am seeing is related to the proxy server setting.
Though Peter and I had eliminated this (we thought) well over a week ago,
there was an additional confounding factor:  converting 4.X profiles (I had
been doing this).   

Unfortunately, I can not easily tell you what proxy server Adobe is using
internally.  When I tried to telnet to it (at port 8080), it refused to identify 
itself
and booted me off.  Further, since everyone is on vacation this week
(to be fiscally conservative in these uncertain times), there isn't anyone I can
ask.  I have a hunch it is a Netscape proxy server. 

I did try one other proxy server here at Adobe and it also caused
mozilla to not display the PDF file (since Mozilla is telling our plug-in
that the stream->end is 0).  Get ready to groan:  this proxy server
is Netscape 1.1! (A very old proxy set up for testing in our group
way back in the good 'old days.)



  

  



    
    

    
  
Well, the proxy setting is entirely the cause of the problem
(see previous comments first).

On the two machines in my office, when I switched to direct connection
(from the Adobe corporate proxy server), initially, my previous
problems with blank screens went away.  

I have been switching back and forth, and unfortunately, even when
the proxy is set to direct connect, I can still encounter a blank
screen (even when I clear the cache in between). 

I strongly encourange Andrei (or someone else who can intelligently
peak under the covers) to come down here today if you can repo this
at your site (I recommend trying a Netscape proxy first). 

  

  



    
    

    
  
using a proxy server here, I don't see the problem (chainsaw.mcom.com)

  

  



    
    

    
  
I forgot an important word in my previous comment:

"Well, the proxy setting is ***NOT***  entirely the cause of the problem
(see previous comments first)."

The only time I can get past the blank PDF page problem is to
disable the Adobe proxy server.  

On the other hand, some times with the Adobe proxy server disabled (a direct
connect to the internet), I still get the blank page problem.

(I will use TCPDump to see if I can peak at what proxy server the
Adobe proxy server is since my other methods didn't work.)


  

  



    
  
Whiteboard: [PDT+] → [PDT+][no eta]

    
    

    
  
Can we summarize the different problems here, this bug is getting fractured.

If there are multiple problems, let's opne seperate bugs and decide which are
PDT+ / nsBranch etc. on them. This current bug seems like a can-of-worms, and it
is PDT+, which makes it a big problem.

  

  



    
    

    
  
Adding more depends bugs:

bug 85529 Some Byte Range requests are returning Bad Bytes [PDT+]
bug 85547 Browser freezes after loading PDF [PDT]

Summary of testcases in this bug that fail:
http://www.svbus.com/KeyStoneUG.pdf  [<-- MAIN TESTCASE]
http://www.samsungusa.com/cmc_upload/product/brochure/170MP.pdf
http://access.adobe.com/browser/netscape/net6.pdf
http://rns.ericsson.se/Solutions/mps/prod_info/mps-g_3/documents/web-01_5542/155
10-CNH_160_230_Rev_F.PDF
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36933

If the other two bugs don't fix these tescase, what do they have in common so
this bug can be fixed?

  

  


Depends on: 85529, 85547

    
    

    
  
Andrei is typing here from Liz's office. Adding gagan, darin as they seem to 
touch/review the questionable code lately:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/ns
HttpTransaction.cpp#430

In this code it looks like we deliberately reject HTTP 1.0 servers and this is 
an actual cause of the problem. When we manually skipped that if statement so it 
doesn't set the lenght to -1 things just worked.

Peter, I beleive this should be reassigned to either gagan or darin.

  

  



    
    

    
  
are you trying this with or without my patches?

  

  



    
    

    
  
This was the tarball (Trunk) from 7/2 4 a.m
with all of Doug's patches applied, and Andrei's patch
for posting binary data. 

  

  



    
    

    
  
A few other points:  I am completely mystified as to why Peter could not
repo this bug.   The server on access.adobe.com is an HTTP 1.0 server.
Any file on Access, therefore, should hit this bug. 

e.g.:

http://access.adobe.com/browser/cookbook.pdf
http://access.adobe.com/browser/netscape/readtesting/Wildtype.pdf


  

  



    
    

    
  
so, let me understand this... by removing that if statement, and applying the
patches which you references, *this* bug goes away.  What about the others?  Can
you load Wildtype.pdf?  

  

  



    
    

    
  
Doug --

I just built my local sandbox (as described in the previous comment)
and also commented out the if statement in nsHTTPTransaction.cpp
that caused Acrobat to fail to load.

Now, I can view Wildtype.pdf (and other PDF files on http 1.0 servers).

But, in the case of Wildtype.pdf, even with your patches I am still
getting page errors. :-(  

This leads me to suspect that there 
are still bad bytes coming (bug 85529) ... I will use my logging tool
and cmp to figure out what is going on. 

  

  



    
    

    
  
Liz (you should probably re-login to Bugzilla, so people don't think it's me), 
with cookbook.pdf test at that breakpoint in nsHTTPTransaction.cpp I don't see 
HTTP content header at all. Only application/pdf content. That's why we don't go 
inside that if statement and that's why I don't see the bug. 

  

  



    
    

    
  
note, that there are two patches in the multimix convert bug.  Most of us like
the second patch.  If that is producing bad output, try the former patch.

  

  



    
    

    
  
Opened bug 89191 Acrobat fails to load PDFs from HTTP/1.0 only servers. Marking
depends.

Looks like there are still 2 other bugs blocking this one, both with patches:
bug 85229 some byte range requests are returing bad bytes
bug 85547 browser freeze after loading pdf

After those are fixed, I can probably get a better idea about what else is
preventing the other testcases from working.

  

  


Depends on: 89191

    
    

    
  
both are assigned to me.  Both I do not know why their are failures.  Try the
second to last patch in bug 85229 and verify that necko is downloading the
correct bytes.  (the last patch doesn't seam to work on the first two reads).

  

  



    
    

    
  
Adding new depend.

  

  


Depends on: 89397

    
  
No longer depends on: 89397

    
    

    
  
*** Bug 85546 has been marked as a duplicate of this bug. ***

  

  



    
    

    
  
I have fixed this problem.  Please verify with tomorrow's trunk or branch 
builds/

  

  


Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
Works on windows branch and trunk 0706 builds. All testcases load absolutely 
fine. will check if this also magically fixes 89431 and comment there. VERIFIED

  

  


Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 89631 has been marked as a duplicate of this bug. ***

  

  



    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: