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.
Component: General → Style System (CSS)
Product: Firefox → Core
Component: Style System (CSS) → Layout: Tables
QA Contact: general → layout.tables
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.
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.
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.
The suggested workaround does the trick. Feel free to close this bug as a duplicate of the relevant known bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 148810
You need to log in before you can comment on or make changes to this bug.