loading of acrobat 5 pdf fails sometimes

VERIFIED FIXED in mozilla0.9.3



18 years ago
18 years ago


(Reporter: spamnet, Assigned: peterlubczynski-bugs)



Windows 2000
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+][no eta], URL)


(2 attachments)



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


18 years ago
Keywords: acrobat

Comment 1

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

Comment 2

18 years ago
Confirming on 2001051720 Win2k with Acrobat 5.0.1 2001/03/27.
Ever confirmed: true

Comment 3

18 years ago

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

Assignee: av → peterlubczynski

Comment 4

18 years ago

The file displays fine if loaded in the standalone Acrobat Reader.


18 years ago
Keywords: nsbeta1
Priority: -- → P2

Comment 5

18 years ago
the test url does not load in my 4.x either...

Comment 6

18 years ago
Yes, it's failing for me.  w2k. Mozilla 0.9.

Comment 7

18 years ago
Btw, this also fails on Windows ME. For me it fails always, not just sometimes.
Currently using build 2001052904.

Comment 8

18 years ago
Works nicely after bug 82415 and bug 53363 get fixed. Try the patch in bug 
Depends on: 53363, 82415

Comment 9

18 years ago
I just checked in the patch that should make this now load and work just fine. 
Marking FIXED. If it doesn't please reopen.
Last Resolved: 18 years ago
Resolution: --- → FIXED
This is still failing for me on Windows ME using build 2001053104. Is the patch
included in this build?

Comment 11

18 years ago
Resolution: FIXED → ---
Here is a talkback ID from a crash opening a .pdf earlier today:

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.

Comment 13

18 years ago
Can someone kick the Talkback server and attach the stack to this bug? I keep 
getting this error:

                     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>
                        405: <cfset vendorName=FCQuery.GetFormattedBlackBoxKey( 
bbid, "SVendor ID", "Plain text")>
                        406: <cfset vendorName=Trim(StripCR(vendorName))>
Keywords: crash

Comment 14

18 years ago
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)  
[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)  
<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.

Comment 16

18 years ago
[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?]

Comment 17

18 years ago
peter: for future talkback queries, try this url : http://climate/main/qfa.cfm
Build: 2001060120

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 
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.
Created attachment 36933 [details]
pdf file that is not loading correctly
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...

Comment 21

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

Comment 22

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

Comment 24

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

Comment 25

18 years ago
Got another failing testcase:


I wanted to buy this monitor :(

Comment 26

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

Comment 27

18 years ago
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."
PDF file does not display in browser. Also, see notes. 

Comment 28

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

Comment 29

18 years ago
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]

Comment 30

18 years ago
nominating nsbranch
Keywords: nsbeta1 → nsBranch
Whiteboard: [byte-range]
Target Milestone: --- → mozilla0.9.2

Comment 31

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

Comment 32

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


Comment 33

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

Comment 34

18 years 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 
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 
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. 

Comment 35

18 years ago
Created attachment 40475 [details]
Javasnooper logging proxy server tool

Comment 36

18 years ago
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 
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 "" -- 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.

Comment 37

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

Comment 38

18 years ago
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.)

Comment 39

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


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

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

Comment 40

18 years ago
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)

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.

Comment 41

18 years ago
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 {

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:

      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.


Comment 42

18 years ago

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.

Comment 43

18 years ago
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:


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

Comment 44

18 years ago
on my regulat conenction speed...it loaded this url  
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....


18 years ago
Whiteboard: [PDT+]

Comment 45

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

Comment 46

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

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.

Comment 47

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

Comment 48

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

Comment 49

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


18 years ago
Blocks: 85529

Comment 50

18 years ago
wait.. which way.

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

Comment 51

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

Comment 52

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

Comment 53

18 years ago
I have some new data:

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

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

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 
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.)

Comment 54

18 years ago
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). 

Comment 55

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

Comment 56

18 years ago
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.)


18 years ago
Whiteboard: [PDT+] → [PDT+][no eta]

Comment 57

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

Comment 58

18 years ago
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]

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

Comment 59

18 years ago
Andrei is typing here from Liz's office. Adding gagan, darin as they seem to 
touch/review the questionable code lately:

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.

Comment 60

18 years ago
are you trying this with or without my patches?

Comment 61

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

Comment 62

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



Comment 63

18 years ago
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?  

Comment 64

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

Comment 65

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

Comment 66

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

Comment 67

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

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

Comment 68

18 years ago
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).

Comment 69

18 years ago
Adding new depend.
Depends on: 89397


18 years ago
No longer depends on: 89397

Comment 70

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

Comment 71

18 years ago
I have fixed this problem.  Please verify with tomorrow's trunk or branch 
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 72

18 years ago
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
*** Bug 89631 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.