There's an example of this from www.valupage.com at http://schist/valupage/index.html. Basically, the problem is this: using the td valign=middle doesn't behave the same way that it does in Comm 4.51 and IE 5. In the older browsers, a buffer zone is kept around the input control and button for a better overall visual effect. In seamonkey, however, there is no buffer around the control or button, which gives a clipped look. If this is intentional, so be it; if not, it's a bug. Here's the HTML itself: <form action="/ValuPage2.pst?From=SMO" method="post" name="Form1"> <input type="hidden" name="Ses" value="19990328151529916"> <input type="hidden" name="Next" value="ValuPage_Step2"> <input type="hidden" name="ValidateNextPage" value="True"> <input type="hidden" name="AddToIni" value="Temp,EnteredZipCode,v_ZipCode"> <input type="hidden" name="AddToIni" value="Header,HouseHolds_ID,0"> <input type="hidden" name="ReplaceBadZip" value="Please Enter A Valid 5 Digit ZipCode"> <table width=620 border=0 cellpadding=4 cellspacing=0 bgcolor="#FFFFFF"> <tr> <td align=center valign=top> <table cellpadding=2 cellspacing=2 border=0 width=340> <tr> <td bgcolor="#FFCC00" align=center colspan=2> <table cellpadding=0 cellspacing=0 border=0> <tr> <td height=12> </td> </tr> <tr> <td valign=middle> <input type="text" name="ZipCode" size=12 value=""> </td> <td width=25> </td> <td valign=middle> <input type="submit" value="Submit Your Zip Code"> </td> </tr> <tr> <td height=12> </td> </tr> </table> </td> </tr> </table> </td> </tr> </table> </form>

Table bugs go to the HTMLTables component...

This effect can be accomplished with a style rule setting the margins on a <input> within a <td>. It should probably be the default behavior in ua.css.

Moving to M8.

Moving to M10.

There already is a testcase for this bug at http://schist/valupage. This testcase is not available outside Netscape; if anyone needs it posted, please ask me. Thanks! - cpratt

cpratt: Since you offered, could we have the test case attached? Thanks!

Attaching simplified test case. Problem appears to occur with any table inside another table cell. May not be inheriting cell's alignment property correctly. Cannot test this bug for table rows while bug 1802 remains open.

Whoops! Re-reading the original bug. The behaviour originally reported is not appearing under M7. Test case attached shows a different bug, ie. the table inside the parent table is not being centred correctly.

cpratt: Thanks for attaching the test case. run2000: The align stuff is caused by bug 7112. I am returning this bug back to its original state and marking it WORKSFORME, as the original bug has been fixed, as far as I can tell. The alternative is to mark this a duplicate of bug 7112, but then we lose track of the original problem, so I've opted for the WORKSFORME resolution.