RESOLVED FIXED 7395
Table not properly re-flowed when floated div removed from layout
https://bugs.webkit.org/show_bug.cgi?id=7395
Summary Table not properly re-flowed when floated div removed from layout
Devin Chalmers
Reported 2006-02-20 12:54:12 PST
When a floated div's style is set to "display:none", the width of tables it was floated next to does not get properly reset, and the table does not flow properly with the rest of the page Possibly similar to Bug 3399 (http://bugzilla.opendarwin.org/show_bug.cgi?id=3399). Steps to reproduce: 1. Float a div next to a table, with the div's style set to "display:none". 2. Using Javascript, set the div's style.display to "block". The table's width is adjusted to account for the width of the div. 3. Using Javascript, set the div's style.display to "none" again. Expected Result: The table's width and page layout return to the div-less layout of step 1 (this is the behavior in Firefox and IE6). Actual Result: The table's width remains at the smaller width as set after in step 2, not matching the original div-less layout. I have created a minimal testcase, will attach after bug is added.
Attachments
Testcase (1.78 KB, text/html)
2006-02-20 12:57 PST, Devin Chalmers
no flags
Fix (no layout test or change log) (789 bytes, patch)
2006-06-09 04:19 PDT, mitz
no flags
Complete patch (74.14 KB, patch)
2006-06-14 10:22 PDT, mitz
hyatt: review+
Devin Chalmers
Comment 1 2006-02-20 12:57:16 PST
Created attachment 6629 [details] Testcase
Devin Chalmers
Comment 2 2006-02-20 12:58:20 PST
Attached test case (added borders and width/height on the div for readability, not necessary for problem to occur). Also, your attachment adding system seems to crap out if you add the optional long description at the bottom of the form. Might be worth looking into.
mitz
Comment 3 2006-06-09 04:19:53 PDT
Created attachment 8783 [details] Fix (no layout test or change log) This fixes the test case and also this CSS2.1 test: css2.1/t0905-c5525-fltmult-00-d-g.html I case I'm concerned about is actually the case that currently works, i.e. the paragraph. The only reason it reflows is that containsFloats() keeps returning true even after the last float is removed (it checks that m_floatingObjects is not 0 but otherwise doesn't check if there are any objects in the list), so layoutInlineChildren always does a full layout (of any block that ever had floats at some point). I think you need a different mechanism for signaling the need for a full layout in the case of a float being removed, but I can't think of one.
Dave Hyatt
Comment 4 2006-06-13 03:06:38 PDT
Comment on attachment 8783 [details] Fix (no layout test or change log) r=me
mitz
Comment 5 2006-06-14 10:22:59 PDT
Created attachment 8846 [details] Complete patch Added ChangeLog entries, layout test, updated test results and a FIXME
Dave Hyatt
Comment 6 2006-06-16 13:25:54 PDT
Comment on attachment 8846 [details] Complete patch r=me (again!)
Adele Peterson
Comment 7 2006-06-17 08:49:54 PDT
committed in r14899.
Note You need to log in before you can comment on or make changes to this bug.