420196 - CSS table cell percentage widths calculated wrong on initial load

Status: RESOLVED DUPLICATE of bug 148810

(Core :: Layout: Tables, defect)

Description

[Kevin Yank]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

When a page contains elements formatted as a CSS table (i.e. display: table and display: table-cell) using the fixed table layout algorithm (i.e. table-layout: fixed), and when column widths are specified as a mixture of absolute and percentage widths, the initial page layout calculates the percentage cell widths incorrectly. When the page is refreshed, or when it is loaded from the cache, the cell widths are calculated correctly.

Reproducible: Always

Steps to Reproduce:
1. Clear the browser cache.
2. Load http://www.sitepoint.com/examples/3col-bug.html
3. Note the second column is 66% of the table width, and the third column is 33% of the table width, causing the table cells to exceed the width of the table. This incorrect behaviour breaks the layout of the page.
4. Click Refresh.
5. Note the second and third column widths are now reduced correctly to fit within the width of the table. This matches the behaviour of Opera and Safari.
6. Type Ctrl/Cmd-Shift-R to perform a hard refresh. Note the layout breaks again.
Actual Results:  
Table cell percentage widths are incorrectly calculated as absolute percentages of the table width on initial page load, then correctly calculated when the page is refreshed from the browser cache.

Expected Results:  
Table cell percentage widths should be correctly constrained by the table's width from the initial page load.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reporter's testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm only seeing a more drastic difference where the third column ends up underneath the others (probably because of one of the dependencies of bug 148810); I haven't actually seen the width variation.

Comment 3

[Kevin Yank]

I took the drastic layout breakage (third column ends up below the others) to be caused by the width variation. That is, it looks like the third column ends up on the next line because there is no room left for it in the row.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

No, the width variation would never cause different row-breaking; the different row-breaking, could, however, cause width variation.

This is probably a known problem related to our handling of "anonymous table objects"; the workaround is to put elements with display:table-row-group and display:table-row explicitly in your document where CSS says they should be implied.

Comment 5

[Kevin Yank]

The suggested workaround does the trick. Feel free to close this bug as a duplicate of the relevant known bug.