Last Comment Bug 27507 - Crash instead of blank page for malformed xhtml page
: Crash instead of blank page for malformed xhtml page
Status: VERIFIED FIXED
[nsbeta2+]6/15
: crash, testcase
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: x86 Windows 2000
: P3 critical (vote)
: M17
Assigned To: rickg
: Jan Carpenter
: Andrew Overholt [:overholt]
Mentors:
: 39112 41003 41243 42789 42938 (view as bug list)
Depends on:
Blocks: 33605
  Show dependency treegraph
 
Reported: 2000-02-12 05:07 PST by Daniel Bratell
Modified: 2000-06-26 18:26 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The minimized testcase (214 bytes, text/html)
2000-02-12 06:58 PST, Daniel Bratell
no flags Details

Description Daniel Bratell 2000-02-12 05:07:32 PST
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.
Comment 1 Daniel Bratell 2000-02-12 06:57:41 PST
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.
Comment 2 Daniel Bratell 2000-02-12 06:58:19 PST
Created attachment 5200 [details]
The minimized testcase
Comment 3 rickg 2000-02-12 11:03:23 PST
One for you and expat I think.
Comment 4 Nisheeth Ranjan 2000-02-15 10:10:21 PST
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.
Comment 5 Nisheeth Ranjan 2000-02-15 13:50:01 PST
Just checked in the fix.
Comment 6 Daniel Bratell 2000-02-17 03:48:49 PST
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.
Comment 7 Nisheeth Ranjan 2000-02-18 12:06:58 PST
Accepting bug...
Comment 8 Nisheeth Ranjan 2000-02-18 13:36:52 PST
Which platform did you test on?  This is working fine for me on today's NT 
build.
Comment 9 Daniel Bratell 2000-02-18 14:27:09 PST
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. 
Comment 10 Nisheeth Ranjan 2000-02-21 16:00:18 PST
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.
Comment 11 Nisheeth Ranjan 2000-03-24 12:13:13 PST
The page is getting blanked out on the latest builds.  Marking worksforme.
Comment 12 Daniel Bratell 2000-05-07 11:14:41 PDT
The testcase still crashes, reopening.
Comment 13 Daniel Bratell 2000-05-07 14:59:32 PDT
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]
Comment 14 Nisheeth Ranjan 2000-05-09 20:16:38 PDT
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.
Comment 15 Gervase Markham [:gerv] 2000-05-15 03:35:37 PDT
*** Bug 39112 has been marked as a duplicate of this bug. ***
Comment 16 Gervase Markham [:gerv] 2000-05-15 03:36:54 PDT
The testcase in bug 39112 is even more minimal than this one. But it may be 
malformed.

Gerv
Comment 17 Gagan 2000-05-15 18:12:22 PDT
->ruslan
Comment 18 ruslan 2000-05-16 10:10:23 PDT
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.
Comment 19 Nisheeth Ranjan 2000-05-22 22:57:42 PDT
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()
Comment 20 harishd 2000-05-23 09:43:33 PDT
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 ***
Comment 21 Daniel Bratell 2000-05-31 11:02:11 PDT
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
Comment 22 harishd 2000-05-31 12:36:23 PDT
Over to rickg. I guess he's been working on a similar bug.
Comment 23 rickg 2000-06-01 11:58:14 PDT
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. 
Comment 24 Michael La Guardia 2000-06-01 17:07:19 PDT
Putting on nsbeta2+ radar.  Will become minus on 6/15
Comment 25 vidur (gone) 2000-06-02 10:43:50 PDT
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.
Comment 26 vidur (gone) 2000-06-02 10:46:14 PDT
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."
Comment 27 Hixie (not reading bugmail) 2000-06-02 10:48:21 PDT
vidur: Eh? I agreed with your first statement, not your correction...
Comment 28 vidur (gone) 2000-06-02 10:50:12 PDT
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."
Comment 29 Karl Ove Hufthammer 2000-06-02 12:35:11 PDT
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!
Comment 30 harishd 2000-06-06 14:06:32 PDT
*** Bug 41243 has been marked as a duplicate of this bug. ***
Comment 31 rickg 2000-06-08 11:53:52 PDT
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).
Comment 32 harishd 2000-06-08 16:57:10 PDT
*** Bug 39112 has been marked as a duplicate of this bug. ***
Comment 33 Nisheeth Ranjan 2000-06-08 17:09:35 PDT
*** Bug 41003 has been marked as a duplicate of this bug. ***
Comment 34 rickg 2000-06-11 11:25:31 PDT
This is fixed, and was related to the mapping of xhtml to text/html mimetypes.
Comment 35 David Hallowell 2000-06-16 03:43:53 PDT
*** Bug 42789 has been marked as a duplicate of this bug. ***
Comment 36 Peter ``jag'' Annema 2000-06-18 01:16:06 PDT
*** Bug 42938 has been marked as a duplicate of this bug. ***
Comment 37 Stephen Walker 2000-06-26 18:26:44 PDT
verifying using 2000062520 nightly on w2k

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