User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041129 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041129 Firefox/1.0 As http://www.w3.org/TR/CSS21/visuren.html#display-prop, when "display" is set to "none", the element has no effect on layout. I set two tbodies in one table and change the value of "display" to show or hide them. But when I set one to "none", it always leaves a blank block there. Reproducible: Always Steps to Reproduce: 1. 2. 3.

move mouse between the "A" and "B" on the top. it is supposed the lower content will change as the mouse moving. However, although the content is change, the length is growing at the same time.

sorry, this is the right case.

in nsTableFrame::CalcDesiredHeight 3426 // get the natural height based on the last child's (row group or scroll frame) rect 3427 nsAutoVoidArray rowGroups; 3428 PRUint32 numRowGroups; 3429 OrderRowGroups(rowGroups, numRowGroups, nsnull); everytime, 'numRowGroups' increases.

Moving to Core product.

display: block for a row-group ?!?? does that issue go away when you toggle between 'none' and ''?

(In reply to comment #5) > display: block for a row-group ?!?? > does that issue go away when you toggle between 'none' and ''? Yes, toggle between 'none' and '' is OK.

THe problem is if all the row-groups in a table toggle from "table-row"/"block" to "none" numRowGroups will be 1.(not 0) If we do so again, numRowGroups will increase. And DesiredHeight is wrong.

No, that's a symptom of the problem. The problem has something to do with frame construction and anonymous table objects.

toggle between "table-row"/"block" and "none" will call nsTableFrame::Destroy toggle between "" to "none" will not. But, if we leave one tbody "display=block" and toggle another one, numRowGroups won't increase.

its probably a dupe of bug 97506

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

Sorry for adding duplicate, but unfortunately the description here doesn't describe the problem which makes it difficult to find. The failure is specfically to do with the Hide/Show handling of the display attribute of a <TR> element. You guys clearly know your way round this code. I don't. I've had a look at the details of bug 97506 and they seem linked by the same logic flaw in code, if not exactly the same. Toggling of the display attibute of text in a <div> doesn't exhibit this characteristic but <div id=a style = "display: none;"><tr> does, which puts the focus clearly on the hide/show handling logic of table display. The test case I provided in bug 306699 shows the behaviour better. The behaviour is as if the logic has a flaw based on Table.Rows.Visible.Count>0 rather than >=0 when recomputing table size AND row offsets for display. Clearly in the =0 case there are no row display offsets to compute, but you still need to recompute the table size.

The recompute might be bug 206516 which went in on 2005-08-30 09:14

the reminder is a dupe of bug 97506 *** This bug has been marked as a duplicate of 97506 ***