266454 - Page with CSS floats renders differently in Trunk and Aviary Branch

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[Ali Ebrahim]

This page (which I will attach after bug submission) displays differently
depending on what user agent you use to view it.

Rendering 1 (see screenshot 1, will be attached shortly):
Mozilla Trunk, 2004-10-27
Firefox AVIARY_1_0_20040515_BRANCH, 2004-10-22

Rendering 2 (see screenshot 2, will be attached shortly):
Firefox AVIARY_1_0_20040515_BRANCH, 2004-10-23

The timing of this change suggests that it may be related to checkins for bug
148994. Boris Zbarsky thinks on first sight that the problem in rendering is
probably on the trunk. I am inclined to agree, because when reducing this
testcase to something smaller (still not small enough, but much smaller than
before), the Aviary branch builds were consistent in their rendering (as in
screenshot 2), whereas the trunk builds were inconsistent, putting the content
in different places depending on what I removed from the content.

I've reduced it as much as I know how to while still showing the rendering
difference. If you remove certain most things, the user agents in "Rendering 1"
will display like the user agents in "Rendering 2".

Sorry if this description is confusing, but I don't know how to better explain it.

Comment 1

[Ali Ebrahim]

Attachment: Original Testcase

Comment 2

[Ali Ebrahim]

Attachment: Original Testcase

Replacing the first original testcase which I put up, which was borked.

Comment 3

[Ali Ebrahim]

Attachment: Rendering 1 / Screenshot 1

Comment 4

[Ali Ebrahim]

Attachment: Rendering 2 / Screenshot 2

Comment 5

[Martijn Wargers (dead)]

I can see the bug with the testcase in the latest Aviary branch build, but I
can't see the bug with the testcase in the latest trunk build. 

I can see the bug with the testcase, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040823
Firefox/0.9.1+ 
(which is in fact 2004-08-24 at 0:26)
But I can't see the bug with the testcase, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040825
Firefox/0.9.1+ (8:01 am)

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Something like a minimal testcase

Comment 7

[Boris Zbarsky [:bzbarsky]]

In that testcase, the float is needed, as is the left padding on the div
containing the other content (so that bug 148994 would have an effect). 
Interestingly, the nested div containing the <br> is also needed, as is the
height on the div below that one.  I could reproduce the bug with heights down
to 202px on that div, but decided to go with 300 for the testcase in case there
was a font-size dependence or something.  The borders are not needed, but
illustrate the difference between trunk and branch -- the div directly around
the br has a different height.  They also indicate that this is NOT a
margin-collapse bug..

I can get the trunk rendering to change by adding text to the red-bordered div.
 If I do that, trunk and branch agree with each other.  The branch rendering of
the testcase is the right one; the trunk is buggy.

The behavior on the trunk was the same as the current branch behavior up through
 (and including) the 2004-08-25-07 build.  2004-08-26-07 renders as current
trunk does.  The most likely culprit for the regression is the fix for bug
256937.  The other possibility is the fix for bug 133165.

roc, any idea what's up here?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It can't be bug 256937, there's no overflowing lines here because we're not
printing or doing columns. But then I don't see how it could be bug 133165 either.

My patch in bug 209694 reworks all this considerably, I wonder if it fixes this.
I'll try to take a look.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Nothing else in that checkin range looks particularly related, as far as I can
tell...  Martijn, don't you have a build with roc's margin patch around?  Could
you test it on this testcase?

Comment 10

[Martijn Wargers (dead)]

(In reply to comment #9)
> Martijn, don't you have a build with roc's margin patch around?  Could
> you test it on this testcase?
Yes, when I test that build with your testcase, the red bordered div gets the
same height as the green div, so that's the same as Aviary branch builds
from/after 2004-10-23. So the patch from bug 209694 seems to fix this bug.

Comment 11

[Ali Ebrahim]

For whatever reason, bz's testcase in attachment 163735 [details] renders the same (for
me) in Mozilla Trunk 2004-10-27 and Firefox AVIARY_1_0_20040515_BRANCH 10/26 on
initial load. In both cases the red div and green div and at the same "level".

*But*, I wonder if this is a reflow bug of some sort, because using bz's
testcase, if using Mozilla Trunk I open the load the testcase (red/green divs
will end level, as I mentioned), but then open another tab and then go back to
the testcase tab, the red div will have shrunk in height to one line tall,
bringing the orange div up.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Incremental reflow with 'clear' is just broken on the trunk (and branch). It's
fixed, I hope, by 209694. So perhaps whatever broke this testcase on trunk
simply put us into a state where the bugs in incremental reflow with 'clear' are
exposed.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, this testcase is an example of where the current code simply fails to take
the 'clear' into account during an incremental reflow because it's in a child
block which is not dirty. This is accounted for by the patch in bug 209694:

> The bad news is that when we reflow a block with a space manager (i.e. a
> containing block for floats), we must reflow any block with a child line which
> has 'clear' set --- and of course the block parents of such blocks, etc.

Comment 14

[Ali Ebrahim]

Adding dependency on bug 209694.

Comment 15

[Martijn Wargers (dead)]

Fixed by bug 209694