254334 - CSS margin-right and margin-left display incorrectly with nested tables.

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Timothy Robinson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040802 Galeon/1.3.16
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040802 Galeon/1.3.16

If margin-left + margin-right < border-width + padding, then the inner table
exceeds the right bounds of the outer table.


Reproducible: Always
Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

The issue is the border-box sizing on the table...  Not clear why that's causing
the problem; a minimal testcase would help here.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 3

[Mats Palmgren (inactive)]

The regression occured between nightly builds 2004-02-02-07 -- 2004-02-03-08.
It was caused by bug 232754.
If I apply the reverse patch from that bug the problem disappears.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So.. that bug actually made us render correctly.  In "Testcase #1" the rendering
is what it should be.

The bug is that there is a discontinuity in the inner width at some point, not
that the inner table overflows the outer table.

Comment 5

[Mats Palmgren (inactive)]

OK, sorry about that.  So you're saying that it's really "broken2" that is the
incorrect layout then?

Comment 6

[Boris Zbarsky [:bzbarsky]]

In my opinion, yes...

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #2, margin-left:51px (broken)

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase #3, margin-left:50px (correct)

Comment 9

[Mats Palmgren (inactive)]

Attachment: From the reflow logs

The 'availSize' for the inner-most TD differs quite a bit...

Comment 10

[Timothy Robinson]

I should have been more clear on which was broken and correct.  I have clarified
my test case and renamed the css classes to show which case I percieve to be
correct and broken.

The problem only occurs when the math I showed previously doen't work out.

This example from the bug you referred to looks like a very similar problem.
http://www.starcraftsector.com/leech/uts-gecko-changes.jpg

Do you agree that an inner table should never exceed the bounds of an outer table?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Do you agree that an inner table should never exceed the bounds of an outer
> table?

No.  In certain overconstrained situations (like here), the inner table should
absolutely overflow the outer table.

Comment 12

[Timothy Robinson]

I disagree.  My understanding is that all of the given contraints are relative
and not absolute.  If the outer table had a defined width, I could see the inner
table extending past it.  In this situation, I see the outer table expanding to
fit the inner table within it.  Do you know of a good forum we could poll or a
document that defines this behaviour (www.w3c.com maybe)?

Have a look at these screenshot with firefox versions 0.8 and 0.9.

http://huli.org/mozillabug/firefox08.gif
http://huli.org/mozillabug/firefox09.gif

Comment 13

[Boris Zbarsky [:bzbarsky]]

> If the outer table had a defined width, I could see the inner table extending
> past it.  In this situation, I see the outer table expanding to fit the inner
> table within it.

The inner table has a width of "100%".  This means "the width of the outer
table".  It also has a positive left margin.

If the outer table is wide enough that the inner table does not overflow, then
the inner table width is not 100% of the outer table width.  So the only way to
satisfy that 100% constraint is to overflow.

The relevant specification is http://www.w3.org/TR/CSS21/

Comment 14

[Timothy Robinson]

> If the outer table is wide enough that the inner table does not overflow, then
> the inner table width is not 100% of the outer table width.  So the only way to
> satisfy that 100% constraint is to overflow.

So, if I had a left-margin on the inner table which is much greater than any
padding, margin and border on the right of both tables, the inner table should
overflow the outer table?

Comment 15

[Boris Zbarsky [:bzbarsky]]

That depends on what the width of the inner table was.  If the inner table is au
to width, the outer table can just stretch to contain the inner table + margin.

But in your case, you are asking the layout engine to solve the equation 
"x = x + 50".  There are no solutions, so constraints stop getting dropped, and
the first constraint to get dropped is the "tables don't overflow" constraint.

Comment 16

[Timothy Robinson]

Check out this example where the right-margin is 0.  These examples represent
x = x + 50, x = x + 51 and x = x + 200 if I understand the equation you listed
correctly.
http://huli.org/mozillabug/example2.html

Please, check out this equation and play with some numbers to see the behaviour.
If margin-left + margin-right < border-width + padding (and margin-left > 0)

PS- What does "au to width" mean?

Comment 17

[Boris Zbarsky [:bzbarsky]]

> These examples represent x = x + 50, x = x + 51 and x = x + 200

Yep.  The bug is that we have a discontinuity between 50 and 51 there..

"au to" should have been "auto".

Comment 18

[Andrej Kacian]

Sorry for cluttering up comments, but is
<http://ticho.yweb.sk/desktop/snap-2004-08-17_09-38-41.jpg> related?

Original site is <http://outdoor.webz.cz/clanek.php?idclanek=57>, to save you
typing the url shown in the screenshot.

Comment 19

[Bernd]

The block reflow does show the error, but is of limited use to find the
responsible frame, especially if it is a not a block frame but a table frame.
Then the frame reflow log is much more efficient. The td shown in the block
reflow log is the anonymous inner table cell frame block (AFAIK).

When using the frame reflow log, the most notible difference between the two
reflows starts at the computed size for the inner table (tbl).

broke case:
         tblO 02511F34 r=2 a=2400,UC c=0,UC cnt=2176
           tbl 0251A218 r=2 a=1788,UC c=1188,1200 cnt=2177
             rowG 0251A3E4 r=2 a=1188,UC c=1188,UC cnt=2178
             
correct case:
          tblO 024AC8E8 r=2 a=2400,UC c=0,UC cnt=2225
            tbl 024AC9F4 r=2 a=1800,UC c=1800,1200 cnt=2226
             rowG 024ACBC0 r=2 a=1800,UC c=1800,UC cnt=2227

So it looks like: that inside the outer table reflow the size for the inner
table frame is wrongly computed. Which is a reasonable place as this is the only
place where table frame handle actively margins.

Comment 20

[Bernd]

the code that causes the problem is from bug 106158 around
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/table/src/nsTableOuterFrame.cpp#1294

Comment 21

[Bernd]

Attachment: patch

the patch brings the check and the action inside the if statement better in
sync.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Bernd, I'm not quite familiar with that code and I'm about to be out of touch
for a week... I'll take a look at the patch after I get back a week from now.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 156564 [details] [diff] [review]
patch

Hrm.... I wonder whether we can move this logic to nsHTMLReflowState somehow...

r+sr=bzbarsky for this patch, though.

Comment 24

[Bernd]

fix checked in

>Hrm.... I wonder whether we can move this logic to nsHTMLReflowState somehow...

it would need a review from David, and he doesn't like the table overflow
avoidance code.