See the referenced URL; the first link is recognized as an active link and can be clicked on, but while the second is rendered properly it cannot be clicked on (mouseover of the link is apparently not recognized). This is with an NGLayout build as of 10 September 1998. The HTML to cause this bug (also at the referenced URL)is surprisingly simple: <TABLE> <TR> <TD ROWSPAN=2> <TABLE> <TR><TD><A HREF="01.html">01</A></TD></TR> <TR><TD><A HREF="02.html">02</A></TD></TR> </TABLE> </TD> </TR> <TR><TD>03</TD></TR> </TABLE> If either the ROWSPAN or the last table row is removed ("03") then the problem goes away. Note that this appears to be the root cause for why half the links on the mozilla.org page <http://www.mozilla.org/> do not work in the NGLayout viewer. (I extracted the above from the mozilla.org HTML source.)

Cool. I saw this behavior a while back and then lost the page. I'll get right on it. -tom

Steve, I think the bounding rects for the frames might be off here. If you watch the cursor changes you can see exactly where the event code stops finding the appropriate target as it checks the children. Only the top half of the '01' link is recognized correctly and none of the '02' link. The '03' bit of text seems to get its event correctly.

there don't seem to be any problems with the bounding rects. I've included two partial frame dumps. The first is the broken test case with the row span, the second is a working version of the test case with the rowspan attribute removed. They are virtually identical. That tells us that the bounding rects of the frames involved don't change in any meaningful way due to the rowspan attribute, and the problem must be elsewhere. frame dump from broken case: TBODY(0)@0125EB60[0,0,T] {0, 0, 12, 28.5}< TR(0)@0125ECB0[0,0,T] {0, 0, 12, 14.25}< TD(0)@0125EE10[0,0,T] {0, 0, 12, 14.25}< *TD(0)@0125FA80[0,0,T] {0, 0, 12, 14.25}< *block<TD>(0)@0125FC40[0,0,T] {0, 0, 12, 14.25}< line 0125FD20: count=1 state=clean,inline,complete {0,0,240,285} ibm=0 obm=0 < A(0)@0125F8C0[0,0,T] {0, 0, 12, 14.25}< Text(0)@0125FA10 {0, 0, 12, 14.25}<> TR(1)@0125FDC0[0,0,T] {0, 14.25, 12, 14.25}< TD(0)@0125FEA0[0,0,T] {0, 0, 12, 14.25}< *TD(0)@0125F3D0[0,0,T] {0, 0, 12, 14.25}< *block<TD>(0)@0125F510[0,0,T] {0, 0, 12, 14.25}< line 0125F5F0: count=1 state=clean,inline,complete {0,0,240,285} ibm=0 obm=0 < A(0)@0125F210[0,0,T] {0, 0, 12, 14.25}< Text(0)@0125F360 {0, 0, 12, 14.25}<> frame dump from working case: TBODY(0)@0125E340[0,0,T] {0, 0, 12, 28.5}< TR(0)@0125E490[0,0,T] {0, 0, 12, 14.25}< TD(0)@0125E5F0[0,0,T] {0, 0, 12, 14.25}< *TD(0)@0125E940[0,0,T] {0, 0, 12, 14.25}< *block<TD>(0)@0125EB00[0,0,T] {0, 0, 12, 14.25}< line 0125EBE0: count=1 state=clean,inline,complete {0,0,240,285} ibm=0 obm=0 < A(0)@0125E780[0,0,T] {0, 0, 12, 14.25}< Text(0)@0125E8D0 {0, 0, 12, 14.25}<> TR(1)@0125EC80[0,0,T] {0, 14.25, 12, 14.25}< TD(0)@0125ED60[0,0,T] {0, 0, 12, 14.25}< *TD(0)@0125F190[0,0,T] {0, 0, 12, 14.25}< *block<TD>(0)@0125F2D0[0,0,T] {0, 0, 12, 14.25}< line 0125F3B0: count=1 state=clean,inline,complete {0,0,240,285} ibm=0 obm=0 < A(0)@0125EE70[0,0,T] {0, 0, 12, 14.25}< Text(0)@0125F120 {0, 0, 12, 14.25}<>

Alright, I'll keep working on it.

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

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

this is fixed. nsTableRowGroupFrame now overrides HandleEvent. Instead of simply checking it's childrens' rects to see if they contain the event point, it asks them nsTableRowFrame::Contains(event point). The row checks its own bounds, and failing that test it asks its children. This can be used as a template for other container frames that have children outside their own bounding rect. We could move Contains() up in the frame class hierarchy and make it a more general purpose mechanism. Interestingly, even though links in row-spanned cells now work, the cursor doesn't change to a hand the way it should. So I'm leaving the bug open, changing the summary slightly, and leaving it assigned to joki. Summary was: "Use of rowspan causes link to be nonclickable in embedded table"

Using 11/30 devprev build on Win 95 and Win NT, verified bug fixed.