Closed Bug 445142 Opened 11 years ago Closed 11 years ago

extra width in table-layout:fixed tables should be distributed proportionally rather than equally

Categories

(Core :: Layout: Tables, defect, P3, major)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b3

People

(Reporter: viren.pathak, Assigned: dbaron)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.9.1, testcase)

Attachments

(3 files, 3 obsolete files)

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.
Version: unspecified → 3.0 Branch
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: 3.0 Branch → Trunk
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.
Keywords: testcase
Any update on this BUG ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
OS: Windows XP → All
Hardware: PC → All
Summary: FF3 :Table with "table-layout: fixed" is not rendered correctly even when width specified on cell → extra width in table-layout:fixed tables should be distributed proportionally rather than equally
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Assignee: nobody → dbaron
Attached file set of examples (obsolete) —
Attached file set of examples
Attachment #348846 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Attachment #348869 - Flags: superreview?(roc)
Attachment #348869 - Flags: review?(bernd_mozilla)
Attached patch patch (obsolete) — Splinter Review
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.
Attachment #348869 - Attachment is obsolete: true
Attachment #348876 - Flags: superreview?(roc)
Attachment #348876 - Flags: review?(bernd_mozilla)
Attachment #348869 - Flags: superreview?(roc)
Attachment #348869 - Flags: review?(bernd_mozilla)
Whiteboard: [needs review]
Attachment #348876 - Flags: superreview?(roc) → superreview+
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.)
Attached patch patchSplinter Review
Same as previous, but with the reftest fixed.
Attachment #348876 - Attachment is obsolete: true
Attachment #349356 - Flags: review?(bernd_mozilla)
Attachment #348876 - Flags: review?(bernd_mozilla)
Comment on attachment 349356 [details] [diff] [review]
patch

although I think you should change 

+ if (specUndist == 0) {
+                        break;
+                    }

to specUndist <= 0
Attachment #349356 - Flags: review?(bernd_mozilla) → review+
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.
Whiteboard: [needs review] → [needs landing]
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
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla1.9.1b3
Depends on: 467141
Blocks: 468557
You need to log in before you can comment on or make changes to this bug.