242981 - {incr} nsTableRowFrame::IR_TargetIsChild fails on coalesced reflows with height changes

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[James]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040507

If you look at http://www.ocf.berkeley.edu/~jamesc/mozilla_bug/index.html, I
show both the correct and incorrect rendering cases.  Test by choosing different
options from the select box multiple times (for both cases).

The good case shows the table cell expanding correctly.  The bad case shows an
incorrect rendering where the new div elements are just laid on top of the
existing table.

The only difference between the two cases is the placement of the line
select_box.selectedIndex = 0; in the function calls insert_div_good() and
insert_div_bad.  I don't see how the placement should matter.  It took me a long
time to debug though.

This page renders correctly in IE/Opera, so I'm assuming its some strange DOM bug.

Reproducible: Always
Steps to Reproduce:
1. Goto http://www.ocf.berkeley.edu/~jamesc/mozilla_bug/index.html
2. Select 2+ choices from the Bad Test select box.
3.

Actual Results:  
Incorrect rendering.

Expected Results:  
The good case shows the expected results.

Comment 1

[R.K.Aa.]

dup of bug 242088?

Comment 2

[James]

(In reply to comment #1)
> dup of bug 242088?

Here is another test case which uses no innerHTML:

http://www.ocf.berkeley.edu/~james/mozilla_bug/index2.html.

The difference between this file and the original test case was that I changed:

new_div.innerHTML = 'foo';
to
new_dix.appendChild(document.createTextNode('foo'));

which should to the same thing.  So I don't think this is related to innerHTML,
but more with how the DOM engine is handling the appendChild.  Dunno if it is
the same problem that's causing bug 242088.

The strange thing about this bug though, is that it varies depending on the
placment of the selectedIndex = 0 line.

Comment 3

[Aaron Kaluszka]

DOM inspector shows the proper height for the TD, but not for the containing TR.
 This means we are rendering properly from the data provided, but the
dimensional calculations are incorrect.  Not sure where this goes, but I'm
pretty sure it's not DOM Core.

Comment 4

[Erik Fabert]

Attachment: Modified testcase

I modified the testcase to demonstrate a few things:

1. The nested table is not needed. The content of the expanding table cell
doesn't has to be an element at all, simple text is enough.
2. The bug can't be triggered automatically, you have to select an option by
hand.
3. I swapped the table cells to show the order isn't important.
4. Forcing the table to be rendered before setting selectedIndex hides the bug.

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #2

FWIW, the bug also occurs using a button.
I also noted that the button has to be within the table for the bug to occur.

Comment 6

[Bernd]

This is reflow bug inside nsTableRowFrame::IR_TargetIsChild. Pressing the button
causes three incr reflows
1. pressing the button (style change button mark it pressed)
2. adding the content to the first cell 
3. releasing the button (style change button mark it released)

2. and 3. are targeted at different childs of the row so they got coalesced on
the row level into a single incr. reflow which then is split for the two childs.

2. increases the cell height
3. uses the old cellheight as found after 1. and does not change it so the old
cellheight will be used for the row height. The first cell will simply expand
into overflow.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Looks like the reflow branch fixed this....  still need a way to test it.