551943 - [BC] Borders from TH are copied to TD on dynamically add row in border-collapse

Status: NEW

(Core :: Layout: Tables, defect)

Description

[Lukasz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9) Gecko/2008052912 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9) Gecko/2008052912 Firefox/3.0

I have the table with border-collapse. The TH cells have left and right borders and TD cell haven't got any borders. Now, when I add dynamically row after the second row in the table, borders from TH seems to be copied to first row TD's.

Reproducible: Always

Steps to Reproduce:
Everything in included source (requires prototype 1.6)
Actual Results:  
Second row TD's have borders like defined for TH's.

Expected Results:  
Second row TD's should have still no borders.

Comment 1

[Lukasz]

Attachment: The test case (requires prototype.js 1.6)

Comment 2

[Lukasz]

Attachment: Before adding the dynamic row

Comment 3

[Lukasz]

Attachment: After adding dynamic row

Comment 4

[Lukasz]

I've forgotten to mention that it was tested on 3.5 version on linux and 3.5.7 version on windows. Futhermore webkit (chrome/safari) and even IE works fine in this case.

The problem can be solved on setting table border-collapse: separated and border-spacing: 0.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.  Looks like there's some cellmap confusion here.  Bernd, any idea where it might be?

Comment 6

[Bernd]

Attachment: test case

Comment 7

[Bernd]

Attachment: reference

Comment 8

[Bernd]

Boris this is basically a sibling of bug 543791. Both bugs demonstrate that while we trigger the correct border collapse area for computation, the computation does not take into account correctly our previous results at the outer edge of this area. In this case the problem is at

5497   // vertical borders indexed in x-direction (cols)
5498   BCCellBorders lastVerBorders(damageArea.width + 1, damageArea.x);
5499   if (!lastVerBorders.borders) ABORT0();
5500   BCCellBorder  lastTopBorder, lastBottomBorder;
5501   // horizontal borders indexed in x-direction (cols)
5502   BCCellBorders lastBottomBorders(damageArea.width + 1, damageArea.x);
5503   if (!lastBottomBorders.borders) ABORT0();

Initializes the borders

4899 BCCellBorders::BCCellBorders(PRInt32 aNumBorders,
4900                              PRInt32 aStartIndex)
4901 {
4902   NS_ASSERTION((aNumBorders > 0) && (aStartIndex >= 0), "program error");
4903   startIndex = aStartIndex;
4904   endIndex   = aStartIndex + aNumBorders - 1;
4905   borders    = new BCCellBorder[aNumBorders]; 
4906 }

This will default to no border, as soon as we compute the reduced damagearea we would need to fill them with old values from the above. As long as we start from row zero everything is fine as we do not have a border above, but in this case we start from row one and then thing s go bad.

Comment 9

[Bernd]

I thought that a patch might not be too difficult but it turns out that the information that is stored in lastVerBorders is usually determined during the computation. The information that is stored  in the cellmap does not allow to easily retrieve the information and to fill up the array again. The information in the cellmap is useful for painting but not for this sort of prepainting computation. The only sensible way that I see to fix this is to fix bug 540256.