Tested 4-20-99 Win32 and Mac build. On the right side of the above URL page, the list item "Open Directory とは？" under "Netscape Open Directory:" is displayed on the right side. I do not know this is I18n bug.

That is caused by an extra <TD> line above the line <LI><SMALL><A HREF="http://info.netscape.com/fwd/ijahdab/http://directory.netscape.com/about.h tml">Open Directory とは？</A> This is a bug in that url, not the bug in the browser.

I reopened this and changed the summary. I created the simple html page in http://babel/bugs/list/error-table3.html I just copied the part of the http://home.jp.netscape.com/jp In the 5.0 5-03-08 build, the first "Netscape Open Directory" is displayed.

the test case http://babel/bugs/list/error-table3.html is invalid. The <TR> and <TD> are not in <TABLE>. I still think this is an invalid bug. I don't think we want to make seamonkey bug to bug compatable w/ 4.x Reassign to karnaze since this is a table error handling issue.

Moving to M9.

I'm looking at the attachment and can't figure out what the bug is describing. It looks similar to Nav4.5 except that the special character after Directory and before F is missing. If that is the bug, please reassign it to rickg.

The problem is error handle for invalid content. The following is invalid. After <TD VALIGN=TOP>, there is an extra <TD> line. Communicator 4.x can displayed without error. <TR> <TD VALIGN=TOP> <TD> <LI><SMALL><A HREF="http://info.netscape.com/fwd/ijahdab/http://directory.netscape.com/about.html">Open Directory </A> </SMALL> </TD> </TR> I reopen this and reasing to rickg.

Frank forgot to reopen.

This file contains non-ascii chars, but they are maintained by the parser. The text rendering code must be stripping this out.

1. The input content model is invalid in the test case as others have said; however, what gecko turns it into *seems* to be acceptable. If not, please reassign to rickg. 2. The invalid input data, in particular this: Directory\201F, is passed through the parser fine and is mapped (using logic from nav4 written by frank tang) into this: Directory\ufffdF 3. Because of #2, when its time to render we rendering nothing instead of the "?" that navigator uses for an *illegal* character. Given all of the above: malformed content and malformed input, I'm rejecting the bug because our handling in gecko is sufficient.