2751 - {css1} margin-bottom on overflowing floated content may be lost

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Hixie (not reading bugmail)]

Exactly sized float element contents are clipped if they are too big - they
should, instead, spill out of the bottom of the float.

See the quoted test page, or this one:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/htmlbodyrendering2.html

The quoted test page explains what should happen.

Comment 1

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

This isn't the only thing that is clipped.  See also bug 2062.

Comment 2

[leger]

Setting all current Open/Normal to M4.

Comment 3

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 4

[kipp]

I've fixed the layout issues for the floating elements; because the horizontal
scrollers don't get disabled you can't see the easter egg :-(

Reassigning to troy to take care of the scrollbar disabling issues.

Comment 5

[troy]

With the latest source I don't see a scrollbar disabling problem. For the bottom
two scrollable DIV elements, I see the horizontal scrollbar is disabled.

What I see that's wrong is that you can't scroll all the way to the bottom and
see the easter egg (in the third example, anyway).

It appears that is because the area-frame height isn't large enough. It looks
like you changed that code today, and no instead of using the space manager it
uses the combined-area instead.

My guess is that the problem is that the padding "1em" isn't being taken into
account and that's why the area frame size is wrong.

I tried a couple of things, but none of it seemed to help

Comment 6

[Hixie (not reading bugmail)]

The scroll bar problem is covered by bug #2180.

Comment 7

[kipp]

Fixed. The easter egg is now readily visible; note that on linux disabled
scrollbars don't look disabled -- they just are inactive.

Comment 8

[Chris Petersen]

Fixed in March 26th Build.

Comment 9

[Hixie (not reading bugmail)]

Arg! Now floats grow! This is a very recent regression.

I am reopening this bug, because somehow floats have started growing to fit
their contents again, completely counter to the spec.

If a float is given an explicit height, it should have that height, REGARDLESS
of the contents. Ditto for width. This is not happening at the moment.

(Note, though, that a float with width:auto may, if one is not too pedantic in
reading the CSS specs, actually grow (horizontally) to fit the contents. A
float with height:auto should definitely grow vertically to fit the contents.)

The following test case shows the problems:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/floatgrowth.html

Comment 10

[kipp]

I'd like a better test case - Specificially, one that is for this very bug.
Combo tests are not quite as useful as it takes awhile to figure out *which*
test is broken.

Comment 11

[kipp]

You have a slight bug in the test - the "white bar" is only 1px high instead of
1em. I have this fixed in my tree; hopefully it will land today.

Comment 12

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

Attachment: simple testcase

Comment 13

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

The above testcase regressed between the builds 1999-07-14-08-M8 and
1999-07-15-12-M9.

Comment 14

[kipp]

Thanks for the test case. I've checked in the fix.

Comment 15

[Hixie (not reading bugmail)]

Kipp, you say:
> You have a slight bug in the test - the "white bar" is only 1px
> high instead of 1em.
This is incorrect. My test is actually correct; the 1px white border is
merely to stop the margins from collapsing into each other and can be ignored.

The 1em white bar at the bottom is the *margin* which is letting the colour of
the *container*'s background (the <DIV class=contain>) through. That is to say,
the overflowing content of the float goes all the way up to the end of the
bottom margin of the last box in the float, and so the container's overflow
property should let the user scroll all the way to the bottom of the margin.

Currently, we are probably deciding that margins are not content and so we only
let the user scroll to the lowest border, which means that there is no way of
giving a margin to overflowed floated content.

Comment 16

[kipp]

Thanks for the clarification.It could be that the white bar is not visible
because of the horizontal scrollbar (a bug). Or it could be some bit-rot in the
margin collapsing code (a different bug). Feel up to writing another test case?

Comment 17

[Hixie (not reading bugmail)]

Eventually...
I've put it on my radar for now, and am reopening the bug with an updated
summary line. Expect a test case within two weeks. (But if I have not done it
by 1999/09/08 then ping me.)

Comment 18

[kipp]

This can wait until after beta

Comment 19

[Hixie (not reading bugmail)]

Broke out bug 13497 for the overflowed content thingy. Turns out it's a problem
with the handling of 'overflow'. This bug can be marked fixed, the floater
problems have been solved.

Comment 20

[kipp]

Ian says it's fixed, and that's good enough for me :-)

Comment 21

[Chris Petersen]

With the Sept 23 rd, this problem appears to be fixed.

Comment 22

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...