Closed Bug 27507 Opened 25 years ago Closed 24 years ago

Crash instead of blank page for malformed xhtml page

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bratell, Assigned: rickg)

References

Details

(Keywords: crash, testcase, Whiteboard: [nsbeta2+]6/15)

Attachments

(1 file)

The minimized testcase
214 bytes, text/html
Details 
From Bug Helper:
User-Agent: Mozilla/4.7 [en] (WinNT; I)
BuildID:    
When encountering a bad tag on a page with the start:

<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD 
XHTML 1.0 Transitional//EN" "http:
//www.d.lintek.liu.se/css/xhtml-dsektionen.dtd">
<html xmlns="http://www.w3.org/Profiles/xhtml1-strict"><head>

an ASSERT(0) is triggered.
Reproducible: Always
Steps to Reproduce:
1. start Mozilla with mozilla http://www.d.lintek.liu.se
Actual Results:  Crash (or ASSERT(0) mor exact with the stack trace:
NTDLL! 77f9f9df()
HTMLContentSink::NotifyError(HTMLContentSink * const 0x02988d28, const 
_nsParserError * 0x028ac968) line 4429   36 bytes
CWellFormedDTD::HandleErrorToken(CToken * 0x028acad0) line 683   36 bytes
CWellFormedDTD::HandleToken(CWellFormedDTD * const 0x029f0cc8, CToken * 
0x028acad0, nsIParser * 0x029aa788) line 505   12 bytes
CWellFormedDTD::BuildModel(CWellFormedDTD * const 0x029f0cc8, nsIParser * 
0x029aa788, nsITokenizer * 0x029f0d30, nsITokenObserver * 0x00000000, 
nsIContentSink * 0x02988d28) line 258   20 bytes
nsParser::BuildModel() line 1083   34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 998   11 bytes
nsParser::OnDataAvailable(nsParser * const 0x029aa78c, nsIChannel * 0x02a4edc0, 
nsISupports * 0x00000000, nsIInputStream * 0x0228af54, unsigned int 0, unsigned 
int 7160) line 1377   19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x02141c18, 
nsIChannel * 0x02a4edc0, nsISupports * 0x00000000, nsIInputStream * 0x0228af54, 
unsigned int 0, unsigned int 7160) line 256   46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x0228af50, nsIChannel * 0x02a4edc0, nsISupports * 0x00000000, nsIInputStream * 
0x02a75bf0, unsigned int 0, unsigned int 7160) line 1122
nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 
0x02259038, nsIChannel * 0x02a4425c, nsISupports * 0x02a4edc0, nsIInputStream * 
0x02a75bf0, unsigned int 0, unsigned int 7160) line 194   58 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x022fcd10) 
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0234a7f0) line 93   12 bytes
PL_HandleEvent(PLEvent * 0x0234a7f0) line 526   10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00d13758) line 487   9 bytes
_md_EventReceiverProc(HWND__ * 0x001f0d84, unsigned int 49555, unsigned int 0, 
long 13711192) line 975   9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00d13208) line 404
main1(int 2, char * * 0x00b76d10, nsISplashScreen * 0x00000000) line 562   32 
bytes
main(int 2, char * * 0x00b76d10) line 675   17 bytes
mainCRTStartup() line 338   17 bytes
KERNEL32! 77e87903()

The output on the console was:

Expected Results:  Shown the page.
The webmaster are going to fix the error in the output from the web server. I 
will try to grab the output before he does and attach it.
I managed to minimize the file that crashed Mozilla to:
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD 
XHTML 1.0 Transitional//EN" "http:
//www.d.lintek.liu.se/css/xhtml-dsektionen.dtd">
<html><head></head><body>
</om>
</body></html>


Soon coming to an attachment near you.
Summary: Malformed data causes mozilla to crash → Malformed xhtml page causes mozilla to crash
Attached file The minimized testcase — 

    
    

    
  
One for you and expat I think.
Assignee: rickg → nisheeth

    
    

    
  
There was a bogus assert in the HTML content sink.  I have the fix ready to go. 
 Will check it in once the tree opens.
Status: NEW → ASSIGNED
Target Milestone: M14

    
    

    
  
Just checked in the fix.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
The minimal testcase no longer asserts but instead hangs the browser (no 
reaction to mouse clicks), once (forgot to check the stack trace) followed by a 
crash after a couple of impatient clicks by the mouse. I reopen the bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Malformed xhtml page causes mozilla to crash → Malformed xhtml page causes mozilla to hang and then crash

    
  
Severity: normal → critical
Keywords: crash

    
    

    
  
Accepting bug...
Status: REOPENED → ASSIGNED

    
    

    
  
Which platform did you test on?  This is working fine for me on today's NT 
build.

    
    

    
  
The "hang" is still there with a build only a couple of minutes old. It's in 
Windows 2000 (I've changed the platform). The application was completely hung 
though. The mouseover functions in the UI worked (back button and the like was 
changed when the pointer moved over). I tried to pause the run a couple of 
times, but didn't see any thread obviously stuck in a loop. 

The threads I see are in
nsAppShellService::Run
nsDNSService::Run
_PR_WaitCondVar
_PR_MD_PR_POLL (in some WinSock call)

Several times I crashed with illegal memory access after pausing and restarting 
the program. It was a trashed (or at least not legal) mParent pointer in 
nsGenericElement::HandleDOMEvent. You can have the stack trace if you want.

      if (mParent) {
        // Pass off to our parent.
==>     mParent->HandleDOMEvent(aPresContext, aEvent, aDOMEvent, 
                                NS_EVENT_FLAG_CAPTURE, aEventStatus);
      } else {
        //Initiate capturing phase.  Special case first call to document
        if (nsnull != mDocument) {
          mDocument->HandleDOMEvent(aPresContext, aEvent, aDOMEvent, 
                                    NS_EVENT_FLAG_CAPTURE, aEventStatus);


I clear the URL which no longer contains malformed xhtml. 
URL: http://www.d.lintek.liu.se
OS: Windows NT → Windows 2000

    
    

    
  
I just tested this on Win 2000 and the app does not hang or crash. But, a the page does not blank out as it should when you load the attached XHTML file. Lowering the severity, updating the summary and setting a new target milestone.
Severity: critical → minor
Summary: Malformed xhtml page causes mozilla to hang and then crash → Blank page not shown for malformed xhtml page
Target Milestone: M14 → M17

    
    

    
  
The page is getting blanked out on the latest builds.  Marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME

    
    

    
  
The testcase still crashes, reopening.

Severity: minor → critical
Status: RESOLVED → REOPENED
Keywords: testcase
Resolution: WORKSFORME → ---

    
    

    
  
I tried in Purify and once got a ABW (Array Bounds Write) in 
LookupAccountnameW (with no mozilla code in the short stack Purify reported) and 
once a Null Pointer Read with the following stack trace. Disturbing with so 
different events.

    memcpy         [memcpy.asm:109]
    nsByteArrayInputStream::Read(char *,UINT,UINT *) 
[nsByteArrayInputStream.cpp:72]
    InterceptStreamListener::Read(char *,UINT,UINT *) [nsCachedNetData.cpp:1177]
    nsParser::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream 
*,UINT,UINT) [nsParser.cpp:1816]
    nsDocumentOpenInfo::OnDataAvailable(nsIChannel *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsURILoader.cpp:187]
    nsHTTPFinalListener::OnDataAvailable(nsIChannel *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsHTTPResponseListener.cpp:1190]
    InterceptStreamListener::OnDataAvailable(nsIChannel *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsCachedNetData.cpp:1164]
    nsHTTPChunkConv::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream 
*,UINT,UINT) [nsHTTPChunkConv.cpp:208]
    nsHTTPServerListener::OnDataAvailable(nsIChannel *,nsISupports 
*,nsIInputStream *,UINT,UINT) [nsHTTPResponseListener.cpp:526]
    nsOnDataAvailableEvent::HandleEvent(void) [nsAsyncStreamListener.cpp:406]
    nsStreamListenerEvent::HandlePLEvent(PLEvent *) 
[nsAsyncStreamListener.cpp:97]
    PL_HandleEvent [plevent.c:575]


    
    

    
  
The test case now crashes with the following call stack:

memcpy(unsigned char * 0x02b12460, unsigned char * 0x00000000, unsigned long 
214) line 171
nsByteArrayInputStream::Read(nsByteArrayInputStream * const 0x032390a0, char * 
0x02b12460, unsigned int 214, unsigned int * 0x0012fa68) line 72 + 34 bytes
InterceptStreamListener::Read(InterceptStreamListener * const 0x035b8364, char * 
0x02b12460, unsigned int 214, unsigned int * 0x0012fa68) line 1177 + 38 bytes
nsParser::OnDataAvailable(nsParser * const 0x035bff34, nsIChannel * 0x035b3380, 
nsISupports * 0x00000000, nsIInputStream * 0x035b8364, unsigned int 0, unsigned 
int 214) line 1818 + 30 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x035b35f0, 
nsIChannel * 0x035b3380, nsISupports * 0x00000000, nsIInputStream * 0x035b8364, 
unsigned int 0, unsigned int 214) line 187 + 46 bytes
nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x035b3510, 
nsIChannel * 0x035b3380, nsISupports * 0x00000000, nsIInputStream * 0x035b8364, 
unsigned int 0, unsigned int 214) line 1225 + 46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x035b8360, nsIChannel * 0x035b3380, nsISupports * 0x00000000, nsIInputStream * 
0x032390a0, unsigned int 0, unsigned int 214) line 1165
nsHTTPChunkConv::OnDataAvailable(nsHTTPChunkConv * const 0x02aaa460, nsIChannel 
* 0x035b3380, nsISupports * 0x00000000, nsIInputStream * 0x035b87fc, unsigned 
int 0, unsigned int 5) line 208 + 46 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x035b8880, 
nsIChannel * 0x032cacc4, nsISupports * 0x035b3380, nsIInputStream * 0x035b87fc, 
unsigned int 417, unsigned int 5) line 544 + 67 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x035bac30) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x035babe0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x035babe0) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01469530) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00a703bc, unsigned int 49349, unsigned int 0, 
long 21402928) line 1030 + 9 bytes
USER32! 77e71820()
01469530()

Passing to Gagan, Mr. Necko, and ccing Harish, Mr. Parser.
Assignee: nisheeth → gagan
Status: REOPENED → NEW

    
    

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

    
    

    
  
The testcase in bug 39112 is even more minimal than this one. But it may be 
malformed.

Gerv

    
    

    
  
->ruslan
Assignee: gagan → ruslan

    
  
Status: NEW → ASSIGNED

    
    

    
  
All small testcases work for me. The original test cases still crashes but the 
stack trace points to the parser. I examined the path from Necko and haven't 
found anything out of the ordinary. I don't see any chunk converters or cache 
being invovled on the stack at all, though it crashes on the first load. 
Reassgning back.
Assignee: ruslan → nisheeth
Status: ASSIGNED → NEW

    
    

    
  
I see the following call stack with today's build.  Harish, this will probably 
be fixed once you checkin your changes to XML error handling.  Re-assigning to 
you so that you can double check.  Thanks.

HTMLContentSink::CreateContentObject(const nsIParserNode & {...}, nsHTMLTag 
eHTMLTag_parsererror, nsIDOMHTMLFormElement * 0x00000000, nsIWebShell * 
0x00000000, nsIHTMLContent * * 0x0012f6d4) line 949 + 48 bytes
SinkContext::OpenContainer(const nsIParserNode & {...}) line 1244 + 69 bytes
HTMLContentSink::OpenContainer(HTMLContentSink * const 0x0481feb0, const 
nsIParserNode & {...}) line 2903 + 18 bytes
CWellFormedDTD::HandleStartToken(CToken * 0x03899d80) line 616 + 22 bytes
CWellFormedDTD::HandleErrorToken(CToken * 0x03c7ab80) line 677
CWellFormedDTD::HandleToken(CWellFormedDTD * const 0x03c7b530, CToken * 
0x03c7ab80, nsIParser * 0x04816d60) line 505 + 12 bytes
CWellFormedDTD::BuildModel(CWellFormedDTD * const 0x03c7b530, nsIParser * 
0x04816d60, nsITokenizer * 0x03c7b330, nsITokenObserver * 0x00000000, 
nsIContentSink * 0x0481feb0) line 257 + 20 bytes
nsParser::BuildModel() line 1561 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 1445 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x04816d68, nsIChannel * 0x046fff30, 
nsISupports * 0x00000000, nsIInputStream * 0x04823ce4, unsigned int 0, unsigned 
int 214) line 1891 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x046fabc0, 
nsIChannel * 0x046fff30, nsISupports * 0x00000000, nsIInputStream * 0x04823ce4, 
unsigned int 0, unsigned int 214) line 189 + 46 bytes
nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x046cde30, 
nsIChannel * 0x046fff30, nsISupports * 0x00000000, nsIInputStream * 0x04823ce4, 
unsigned int 0, unsigned int 214) line 1217 + 46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x04823ce0, nsIChannel * 0x046fff30, nsISupports * 0x00000000, nsIInputStream * 
0x03c7bb40, unsigned int 0, unsigned int 214) line 1165
nsHTTPChunkConv::OnDataAvailable(nsHTTPChunkConv * const 0x03f2cc98, nsIChannel 
* 0x046fff30, nsISupports * 0x00000000, nsIInputStream * 0x049b450c, unsigned 
int 0, unsigned int 221) line 208 + 46 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x049b58f0, 
nsIChannel * 0x048282a4, nsISupports * 0x046fff30, nsIInputStream * 0x049b450c, 
unsigned int 0, unsigned int 221) line 540 + 67 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x048241f0) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x04824090) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x04824090) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x02d54240) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0bd90288, unsigned int 49367, unsigned int 0, 
long 47530560) line 1030 + 9 bytes
USER32! 77e71820()
02d54240()

Assignee: nisheeth → harishd

    
    

    
  
The crash is due to a mismatch between mimetime ( text/html ) and the content ( 
XML PI ).  Therefore, we ended up choosing WellFormedDTD ( for XHTML ) even 
though the sink given to the parser was HTMLContentSink.  Rickg, has a fix in 
his tree and will be checking in soon.  

*** This bug has been marked as a duplicate of 39520 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE

    
    

    
  
This still crashes when the dupe is marked fixed so I reopens it. Tested with a 
CVS build from 2000-05-28.

Two assertions about failed aName.length() (nsNodeInfoManager.cpp line 155) and 
then a crash with the following stack trace:

SinkContext::CloseContainer(const nsIParserNode & {...}) line 1346 + 3 bytes
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x02f05008, const 
nsIParserNode & {...}) line 2927 + 18 bytes
CWellFormedDTD::HandleEndToken(CToken * 0x024cd3c0) line 662 + 31 bytes
CWellFormedDTD::HandleErrorToken(CToken * 0x02ff1f50) line 709
CWellFormedDTD::HandleToken(CWellFormedDTD * const 0x0306a328, CToken * 
0x02ff1f50, nsIParser * 0x02f39178) line 526 + 12 bytes
CWellFormedDTD::Terminate(nsIParser * 0x02f39178) line 362 + 20 bytes
nsParser::Terminate() line 1091 + 33 bytes
nsParser::Tokenize(int 0) line 2055 + 11 bytes
nsParser::ResumeParse(int 1, int 0) line 1488 + 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x02f39180, nsIChannel * 0x030a4dc8, 
nsISupports * 0x00000000, nsIInputStream * 0x02f04b5c, unsigned int 0, unsigned 
int 214) line 1937 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x02f00bd8, 
nsIChannel * 0x030a4dc8, nsISupports * 0x00000000, nsIInputStream * 0x02f04b5c, 
unsigned int 0, unsigned int 214) line 210 + 46 bytes
nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x030a4688, 
nsIChannel * 0x030a4dc8, nsISupports * 0x00000000, nsIInputStream * 0x02f04b5c, 
unsigned int 0, unsigned int 214) line 1217 + 46 bytes
InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 
0x02f04b58, nsIChannel * 0x030a4dc8, nsISupports * 0x00000000, nsIInputStream * 
0x03127aa0, unsigned int 0, unsigned int 214) line 1165
nsHTTPChunkConv::OnDataAvailable(nsHTTPChunkConv * const 0x0301b340, nsIChannel 
* 0x030a4dc8, nsISupports * 0x00000000, nsIInputStream * 0x02f36f9c, unsigned 
int 0, unsigned int 221) line 208 + 46 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x03157758, 
nsIChannel * 0x02e600fc, nsISupports * 0x030a4dc8, nsIInputStream * 0x02f36f9c, 
unsigned int 29301, unsigned int 221) line 540 + 67 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x031562a0) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03221f98) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03221f98) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e73178) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00991f30, unsigned int 49510, unsigned int 0, 
long 15151480) line 1030 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00e72b98) line 387
main1(int 1, char * * 0x00b67380, nsISupports * 0x00000000) line 904 + 32 bytes
main(int 1, char * * 0x00b67380) line 1188 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

The believed dupe was nsbeta2+ so I nominate this for nsbeta2
Status: RESOLVED → REOPENED
Keywords: nsbeta2
Resolution: DUPLICATE → ---
Summary: Blank page not shown for malformed xhtml page → Crash instead of blank page for malformed xhtml page

    
    

    
  
Over to rickg. I guess he's been working on a similar bug.
Assignee: harishd → rickg
Status: REOPENED → NEW

    
    

    
  
This no longer crashes, but I've fixed a few problems already that may have been 
related. I'll let you know when the changes land, and then you can retest. 

Status: NEW → ASSIGNED
Whiteboard: fix in hand

    
    

    
  
Putting on nsbeta2+ radar.  Will become minus on 6/15

Whiteboard: fix in hand → [nsbeta2+]6/15

    
    

    
  
The bottom line is that if the mimetype is text/html, we should not treat the 
contents as XML, even if it contains an XML decl. This should go through the 
regular codepath for HTML (Parser->CNavDTD/StrictDTD->HTMLContentSink). If the 
mimetype is text/xml, then only should we go through the XML codepath 
(Parser->CWellFormedDTD->XMLContentSink). Mixing and matching is dangerous, IMO.

    
    

    
  
Oops...typo. I meant "The bottom line is that if the mimetype is text/html, we 
should not treat the contents as *HTML*, even if it contains an XML decl."

    
    

    
  
vidur: Eh? I agreed with your first statement, not your correction...

    
    

    
  
OK, I'm confusing myself. I meant to say (and this time I mean it :-) "The 
bottom line is that if the mimetype is text/html, we should treat the 
contents as HTML, even if it contains an XML decl."

    
    

    
  
I disagree (with your final correction). Everybody who writes XHTML, do it on purpose, and *wants* strict (XML) parsing. The only reason they use 'text/html' is for their web pages to be backwards-compatible (and because the XHTML recommendation tells them to!).

The HTML (4.01, not XHTML 1.0) Recommendation doesn't say what user
agents should do when they encounter "bad" HTML. The closest thing I
could find, was Appendix B, which only talkes about unknown elements and
attributes.

In theory, a HTML browser could refuse to display a HTML document that
isn't "well-formed" (not in the XML sense, e.g. _<p>foo<p>baz_ would be
OK, but not _<i>foo<b>baz</i>bar</b>_). It would of course be a very
stupid thing to do, since it wouldn't display most web pages ...

But, when it comes to XHTML, it's *not* a stupid thing to do; IMHO it's
The Right Thing to do!

    
    

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

    
    

    
  
Oh good grief. The XHTML spec itself is very clear. XHTML documents can be 
served as either text/html or text/xml, and we will follow two distinct code 
paths (via the xml sink or the html sink+strict DTD).

    
    

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

    
    

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

    
  
Blocks: 33605

    
    

    
  
This is fixed, and was related to the mapping of xhtml to text/html mimetypes.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

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

    
    

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

    
    

    
  
verifying using 2000062520 nightly on w2k
Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: