386662 - Nested floats within container <div> of width 100% aren't positioned correctly

Status: NEW

(Core :: Layout: Floats, defect)

Description

[cmtalbert]

Attachment: A somewhat minimized testcase that shows the issue

BuildID: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6) Gecko/2007062911 GranParadiso/3.0a6

I found this when testing  Gran Paradiso alpha 6 on Vista, and was able to confirm it on my Intel Mac build also (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6pre) Gecko/20070627 Minefield/3.0a6pre).  I was at the URL above, and clicked on "Launch" on the picture to launch the video content.  However, I didn't have the correct plugins and was redirected to the MSN "get the proper plugin" page.  The buttons along the top were over-writing each other, as you can see in the picture.  When viewed through IE, the second table is displayed to the right of the first, as you can see in that picture.  

If you view the test case with Firefox 2.0.0.4, the test case displays properly.

== Steps to Reproduce ==
1. Browse the testcase above
2. Note that "more" and "Preview the next MSN Video" are stacked atop one another, and the "Preview the next.." set of options should be displayed to the right of the row containing the "more" button.

== Expected Behavior ==
These should not be stacked atop one another.  

== Regression Range ==
I verified that this behavior was caused sometime between GP alpha 1 and GP alpha 2. I can't find those archived nightlies, but if someone has a pointer to them, I'd be happy to narrow that range.  

Here is the bonsai link for the changes from alpha 1 to alpha 2: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-12-07+00%3A00%3A00&maxdate=2007-02-07+00%3A00%3A00&cvsroot=%2Fcvsroot

Comment 1

[cmtalbert]

Attachment: This is a picture of the original website in GP

Comment 2

[cmtalbert]

Attachment: Picture of the testcase in IE 7 on Vista

Comment 3

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

Most likely the reflow branch (bug 300030).  Any chance you could verify that?

The testcase also isn't very minimized...

Comment 4

[Adam Guthrie]

The regression range is kinda weird. Between 2006-12-04-04 and 2006-12-05-05 the layout changed (tables cells were on top of each other instead of beside each other). Then when the reflow branch landed (2006-12-07-04 - 2006-12-08-04) it changed to what you see now.

I'll try to minimize the testcase further.

Comment 5

[Adam Guthrie]

Attachment: minimized testcase

The problem happens with <table>s, but boils down to nested floated <div>s. In a build before the reflow branch, the "Right" floated <span> is floated all the way to the right of the page, but in a reflow branch build the <span> doesn't seem to expend all the way.

Comment 6

[Eli Friedman]

Everybody does this differently... the behavior here is undefined in CSS2.1 because there is no standard for pref-width calculations. (Although note that our current behavior matches Safari's behavior.) And actually, nobody really gets this right; the ideal rendering here would be "leftright".

IE's approach to this testcase is counter to the standard; we essentially can't copy them without breaking CSS2.1 rules.  However preferred width is defined, it definitely isn't supposed to depend on the amount of available space.  (See http://www.w3.org/TR/CSS21/visudet.html#q8)

Comment 7

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

(In reply to comment #5)
> In
> a build before the reflow branch, the "Right" floated <span> is floated all the
> way to the right of the page,

That's completely broken, and I think we had a bunch of bugs on that behavior.  Was that really what the page was depending on?

Comment 8

[Adam Guthrie]

(In reply to comment #7)
> Was that really what the page was depending on?

Pretty much... there is some vertical styling going on, but it basically comes down to it depending on the nested floated right <table> being far enough to the right that it doesn't overlap with the first <table>.

Comment 9

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

But not overlapping is a separate issue -- in the testcase you give, we size the container just big enough so that things *don't* overlap.  How do you then end up with things overlapping?

Comment 10

[Adam Guthrie]

Attachment: minimized testcase (take two)

Here's a minimized testcase that closer reflects reality.

Comment 11

[Ilya]

There is another interesting case with auto width of nested floats that browsers treat differently. It's when there is a block box next to the float (test page for this issue: http://globeprgroup.com/tests/opera-bugs/opera95-ie-bug-css-nested-floats.html).

I believe that the behavior of Opera and IE is correct, because the CSS2.1 spec states that "non-positioned block boxes created before and after the float box flow vertically as if the float did not exist" (section 9.5, "Floats"), and section 10.3.5 ("Floating, non-replaced elements") suggests to calculate the preferred width of the float "by formatting the content without breaking lines other than where explicit line breaks occur".

Should the current behavior of Gecko be corrected?

Comment 12

[Ilya]

I found out that the latest nested floats problem has been already reported in Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=440042