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.
Created attachment 15793 [details] reduced test case
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.
Created attachment 18495 [details] even more reduced test case
Created attachment 18496 [details] even more reduced test case
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.
Suspicious: void FixedTableLayout::calcPrefWidths(int& minWidth, int& maxWidth) { // FIXME: This entire calculation is incorrect for both minwidth and maxwidth.
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...
Colspans don't stretch properly in a lot of circumstances. This bug is in Radar somewhere. It's very old.
(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. :)
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.
Maybe you want to take a stab at this Julien? Or point me at what part of the table layout code to look into.
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.