User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Firefox3 :Table with "table-layout: fixed" is not rendered correctly even when width specified on cell This is regression in FF3. This issue is not re-producible in FF2 , SeaMonkey , IE7, IE Beta 1 In "table-layout:fixed" Tables, if the table is wider than the columns, the extra space should be distributed over the columns proportionally. But FF3 , it distributes the remaining width evenly in all the columns. To re-produce this issue, Create 2 Tables (with 4 columns). WIDTH specified in table 1 is 420px and for second table is 840px. <TABLE ID="Firefox3Test1" WIDTH=420px BORDER=1 STYLE="table-layout:fixed"> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> </TABLE> Ideally for table-layout:fixed when we specify the WIDTH for table column then it should take specified WIDTH and when we re-size the browser window then all column's width should increase or decrease proportionally. <TABLE ID="Firefox3Test2" WIDTH=840px BORDER=1 STYLE="table-layout:fixed"> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> </TABLE> Ideally ,in this case ,width of first column table should be 20px ( exactly double than its value in first Table). But in FF3 , size of first column is 115px ( 10px + 105px) In FF3, it distributes the remaining width evenly in all the columns.( i.e 420px distributed evenly in 4 columns = 105px per column) Distribution of width works fine in other browsers like Firefox 2, SeaMonkey, IE7 , IE 8(beta 1) Reproducible: Always Steps to Reproduce: To re-produce this issue, Create 2 Tables (with 4 columns). WIDTH specified in table 1 is 420px and for second table is 840px. <TABLE ID="Firefox3Test1" WIDTH=420px BORDER=1 STYLE="table-layout:fixed"> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> </TABLE> <TABLE ID="Firefox3Test2" WIDTH=840px BORDER=1 STYLE="table-layout:fixed"> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> <TH WIDTH=10px> &nbsp </TH> <TH WIDTH=200px> &nbsp </TH> </TABLE> Actual Results: While displaying Table "Firefox3Test2" , Width of first column is 115px. Expected Results: While displaying Table "Firefox3Test2" , Width of first column should be 20px.

The CSS 2.1 spec is not not descriptive enough here. In section 17.5.2.1 Fixed table layout, this is covered by: "If the table is wider than the columns, the extra space should be distributed over the columns." But should that distribution be done equally or proportionally? Opera 9.5 also makes the first column 20 pixels wide.

This regressed when the reflow branch landed.

Any update on this BUG ?

Actually, the assertion about pctUndist was too strong for what floating point math can do (and fired on one of the reftests); I fixed it up and actually checked for >100% share in release mode for that case.

Just noticed that some of the reftests are failing on mac due to subpixel text alignment issues; I need to look into that.

(I'm pretty sure the problem is in the test, where I decided to round thirds of a pixel to the nearest pixel.)

Same as previous, but with the reftest fixed.

Comment on attachment 349356 [details] [diff] [review] patch although I think you should change + if (specUndist == 0) { + break; + } to specUndist <= 0

In that case, I wrote the code so it really shouldn't ever get less than zero, but I'll change it and stick an assertion in that it is equal to zero.

There are a couple of SetFinalWidth width calls in between the place where you compute specTotal and where you call specUndist -= colFrame->GetFinalWidth(); and that made me nervous. So the assertion is a good thing. BTW if there is that 2 day flood checkin for 1.9.1, could you please land the patch from bug 458924, I will certainly not be able to meet this time slot. Thanks

Fixed in mozilla-central (and thus also on mozilla-1.9.1): http://hg.mozilla.org/mozilla-central/rev/6ce5f62a5945 Then backed out due to a Mac startup crash, whose underlying cause was actually bug 466399: http://hg.mozilla.org/mozilla-central/rev/1fb559eeb4dd http://hg.mozilla.org/mozilla-central/rev/bf407fc736d7 Then relanded, and thus again fixed in mozilla-central (and thus also on mozilla-1.9.1): http://hg.mozilla.org/mozilla-central/rev/9bea28954d72