WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Fix (no layout test or change log)
(789 bytes, patch)
2006-06-09 04:19 PDT
,
mitz
no flags
Details
Formatted Diff
Diff
Complete patch
(74.14 KB, patch)
2006-06-14 10:22 PDT
,
mitz
hyatt
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug