Bug 3820 – Colspan not working correctly when block type element in <td>

• Status: ASSIGNED
• Component: Tables

[David Storey]

This page uses images of rounded corners, in a table to produce the effect of the main area having 
rounded corners.  In safari (at least in 10.3.9) their is a gap after the first image and the right hand side 
image shows before the end o the nested table inside it.  It works as designed in firefox and IE.  
Reduction forthcoming.

[David Storey]

Created attachment 2759 [details]
a reduction to show problem

A quick reduction in the source to just show the top rounded corners and a
small part of the content area.

[Eric Seidel (no email)]

We'll need further reduction.  I've browsed through other table layout issues today, which may have been 
related to this one.  Beth re-wrote sections of the table code recently (and continues to do so) she may 
also have comments on this bug.

[Joost de Valk (AlthA)]

Created attachment 5326 [details]
Testcase

This show that this is actually a problem with colspan not doing what it should
when a block type element is inside the td.

[Beth Dakin]

I remain confused about what this is supposed to look like. The testcase looks wrong on MacIE and Firefox 
(for the Mac) too. I will need to see what it looks like on WinIE, which I unfortunately can't check right now.

[Joost de Valk (AlthA)]

Created attachment 6470 [details]
Yet another testcase

This should show the bug too, open in firefox to see that second td of second row should NOT start half way but way earlier under the div above. Reduced from: http://www.onlinesoccermanager.nl/info.asp

[Joost de Valk (AlthA)]

Changing component to table.

[Arpita Bahuguna]

This issue can perhaps be marked as a duplicate of https://bugs.webkit.org/show_bug.cgi?id=5515.

[Brent Fulgham]

We do not match Firefox or Chrome for Table 1.

[Radar WebKit Bug Importer]

<rdar://problem/96534555>

[Karl Dubost]

Created attachment 473410 [details]
rendering in safari, firefox, chrome

```
Safari Technology Preview  208           20621.1.5.1
Firefox Nightly            135.0a1       13524.11.25
Google Chrome Canary       133.0.6871.0  6871.0
```

[Karl Dubost]

Created attachment 473411 [details]
testcase with colors and borders

Adding another test case to better see what is happenning.

[Karl Dubost]

Created attachment 473412 [details]
rendering in safari, firefox, chrome (color)

testcase color rendering

[Karl Dubost]

It's like the second row first cell is trying to take half of the space of the colspan of the first row.
while in firefox and chrome the first cell is reduced to its minimum width. 
even a fit-content or min-content on this would not work.

[Karl Dubost]

for example in the first table on my current layout. 

Element Margin Border Padding Width (comment)

TABLE 0 1 0 826
  TBODY 0 0 0 826
    TR  0 0 0 826
      TD 0 1 1 818 (colspan = 2) 
        DIV 0 0 0 100
    TR  0 0 0 826
      TD 0 1 1 47    (total size 1+1+47+1+1 = 51 which is almost half of the DIV)
      TD 0 1 1 765 (width=100%)

if I set the DIV to be 200px
Then the TD of the second row is TD 0 1 1 97 (97 + 4 = 101) again the same type of proportion. 


Currently:

https://searchfox.org/wubkat/rev/5df2953b4ca7158afd166f3f8c130d1a8888cf0f/Source/WebCore/rendering/RenderTableCellInlines.h#66-74
```cpp
inline Length RenderTableCell::styleOrColLogicalWidth() const
{
    Length styleWidth = style().logicalWidth();
    if (!styleWidth.isAuto())
        return styleWidth;
    if (RenderTableCol* firstColumn = table()->colElement(col()))
        return logicalWidthFromColumns(firstColumn, styleWidth);
    return styleWidth;
}
```


and 

https://searchfox.org/wubkat/rev/5df2953b4ca7158afd166f3f8c130d1a8888cf0f/Source/WebCore/rendering/RenderTableCell.cpp#167-197
```cpp
Length RenderTableCell::logicalWidthFromColumns(RenderTableCol* firstColForThisCell, Length widthFromStyle) const
{
    ASSERT(firstColForThisCell && firstColForThisCell == table()->colElement(col()));
    RenderTableCol* tableCol = firstColForThisCell;

    unsigned colSpanCount = colSpan();
    LayoutUnit colWidthSum;
    for (unsigned i = 1; i <= colSpanCount; i++) {
        Length colWidth = tableCol->style().logicalWidth();

        // Percentage value should be returned only for colSpan == 1.
        // Otherwise we return original width for the cell.
        if (!colWidth.isFixed()) {
            if (colSpanCount > 1)
                return widthFromStyle;
            return colWidth;
        }

        colWidthSum += colWidth.value();
        tableCol = tableCol->nextColumn();
        // If no next <col> tag found for the span we just return what we have for now.
        if (!tableCol)
            break;
    }

    // Column widths specified on <col> apply to the border box of the cell, see bug 8126.
    // FIXME: Why is border/padding ignored in the negative width case?
    if (colWidthSum > 0)
        return Length(std::max<LayoutUnit>(0, colWidthSum - borderAndPaddingLogicalWidth()), LengthType::Fixed);
    return Length(colWidthSum, LengthType::Fixed);
}
```

[Karl Dubost]

Created attachment 474939 [details]
testcase with colspan=3

This testcase will make it easier to understand.

	<table>
		<tr>
			<td colspan="3">
				<div style="background-color: gold; width: 100px; height: 100px;"></div>
			</td>
		</tr>
		<tr>
			<td></td>
			<td></td>
			<td style="background-color: pink"
				width="100%"></td>
		</tr>
	</table>

[Karl Dubost]

Created attachment 474940 [details]
rendering in safari, firefox, chrome

What is happening in Safari is a bit clearer. 

1. It computes the width of the second TR depending on the size of the element contained in the first TR (which is 100px)
2. Then distribute equally the space in between the 3 cells of the second row. 
3. Then realizes there is still space aka the TR is a lot wider, and stretches the last cell which is width 100% to the full remaining space of the TR. 

I wonder why the width of the first column stays 100px with the colspan=3  and why it is being reused later something to dig there.