Bug 14856 – table inside a table containing a text line should adjust its size to the inline content

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Matt Perry]

Reduced test case coming up.

Compare the above page (or upcoming test) in Safari and Firefox.  Notice how Safari wraps the last <select> control to the second line, even though there should be enough room to fit them all on the same line.

I've only been able to determine that this is somehow related to <select> controls inside of a table, that the previous <td> has a width percent set, and that the outer <td> has rowspan set.

My vague guess is that the size of a <select> control isn't properly taken into account when determining the width of the table it's inside, and then is wrapped when it turns out to be too big.

[Matt Perry]

Created attachment 15793 [details]
reduced test case

[David Kilzer (:ddkilzer)]

Confirmed with a local debug build of WebKit r24803 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218).

This is not a regression as the same behavior occurs with Safari 2.0.4 (419.3) with original WebKit on 10.4.10.

Renders as expected in Firefox 2.0.0.6 and Opera 9.21.

[Eric Seidel (no email)]

Created attachment 18495 [details]
even more reduced test case

[Eric Seidel (no email)]

Created attachment 18496 [details]
even more reduced test case

[Eric Seidel (no email)]

I suspect this is some incorrect prefWidth calculation.  Possibly the colspan is not taken into account during the layout of the inner table.  Since w/o the col-span the prefWidth for the first td would be 0, with the colspan, it's 500.

[Eric Seidel (no email)]

Suspicious:
void FixedTableLayout::calcPrefWidths(int& minWidth, int& maxWidth)
{
    // FIXME: This entire calculation is incorrect for both minwidth and maxwidth.

[Eric Seidel (no email)]

Actually, this is an AutoTableLayout table, so my previous comment does not apply.  I'm not familiar enough with table layout to know immediately where this bug would be, and thus-far my debugging has not yielded a culprit.  Next bug in the list...

[Dave Hyatt]

Colspans don't stretch properly in a lot of circumstances.  This bug is in Radar somewhere.  It's very old.

[Eric Seidel (no email)]

(In reply to comment #8)
> Colspans don't stretch properly in a lot of circumstances.  This bug is in
> Radar somewhere.  It's very old.
> 

Well, you were looking for old/bad CSS bugs to really enrage you yesterday... I might suggest this is one to get excited about, since if bug 15218 turns out to really be a dupe then this has been seen in 2 major sites. :)

[Dave Hyatt]

If this is the bug I'm thinking of, it's really hard to fix.  Our 2-pass layout system (using min/max pref widths and then laying out) made this one really hard.  However this might just be a completely different issue.

[Elliott Sprehn]

Maybe you want to take a stab at this Julien? Or point me at what part of the table layout code to look into.

[Ahmad Saleem]

I am able to reproduce this bug in Safari Technology Preview 164 and the test case does not show in one line like Chrome Canary 112 and Firefox Nightly 112.

[Frances Cornwall]

Related to https://bugs.webkit.org/show_bug.cgi?id=20426.

[Frances Cornwall]

Related to: https://bugs.webkit.org/show_bug.cgi?id=15218.

[Radar WebKit Bug Importer]

<rdar://problem/127075679>

[Karl Dubost]

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

Adding 
body * {outline: 1px solid purple}

to better see what is happenning.

[Karl Dubost]

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

Or to give a bit of space to breathe and two different colors for tables. 

body > table * {
  padding: 1ch;
  outline: 1px dashed purple;
}

table table * {
  outline: 1px dashed red;
}


Basically it looks like the width the table inside the td colspan="2" is not large enough.

[Ahmad Saleem]

Created attachment 472816 [details]
WebKit ToT Result

Based on Karl's input, I updated test case: https://jsfiddle.net/w7zrad1L/

and WebKit ToT () seems to have progressed this as can be seen from attachment.

Marking this as 'RESOLVED CONFIGURATION CHANGED' (till we figured out what progressed this).

Just to flag - Safari Technology Preview 204 is still broken.

[zalan]

This has progressed at 283711@main

*** This bug has been marked as a duplicate of bug 279450 ***