7093 - two overlapping tables when first table floating

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[joecm]

The tables seem to overlap.

Build: 1999051808

Comment 1

[rickg]

Attachment: Simple reduction of given page.

Comment 2

[rickg]

I've added a reduced case (attachment). Please try to fix the table bug, and if
there's also a layout bug, pass it to kipp.

Comment 3

[karnaze (gone)]

Troy, please take a look at this.

Comment 4

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

This is triggered by the following sequence:

* block level element with bottom margin nonzero (anything nonzero)
* table, any size, floated left (including align=left)
* table, any size

attaching simpler test case.  I imagine this has something to do with how you
make tables an exception from the block-level flow-around-floats rules.  See,
perhaps, my proposal for float-displace, in which I think tables would have the
value block (I think that's legacy behavior):
http://lists.w3.org/Archives/Public/www-style/1998Dec/0082.html
One question is how to handle this in standard mode...I would say do it the
legacy way, since the spec doesn't really address this very well.

Comment 5

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

Attachment: Even simpler reduction.

Comment 6

[troy]

Kipp, this is a pretty bug change and with the table work I won't get to it for
a while

Comment 7

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

*** Bug 12626 has been marked as a duplicate of this bug. ***

Comment 8

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

*** Bug 12626 has been marked as a duplicate of this bug. ***

Comment 9

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

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1416 is a slight
variant from bug 12626 involving a form element.

Comment 10

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

*** Bug 15134 has been marked as a duplicate of this bug. ***

Comment 11

[Brendan Eich [:brendan]]

Dmose says that this bug makes calendar.yahoo.com utterly useless.  He argues it
should be fixed for dogfood.

/be

Comment 12

[kipp]

Note for me: the bug has to do with the fact that the available space computed
for the floater is computed at the wrong location - the block reflow context is
computing the top margin and after that's computed we need to get the available
space so that we know what the proper floater impacts are. To fix this I need to
reconfigure block reflow context to break out the top margin computation in
advance of the reflow. However, to do that is a royal pain because the top
margin calculations depend on the containing block width (maybe - if they are
percentages) and all of that logic is rolled up into nsHTMLReflowState's ctor
and would require alot of work to fix.

urk.

Comment 13

[kipp]

Fixed. I updated the block reflow logic to pre-compute the top-margin and use
that to properly determine the available reflow space.

Comment 14

[Chris Petersen]

In the Oct 21 build (1999102109), this problem is fixed.