Joey Bowles Reporter
	Description • 18 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070409 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070409 Minefield/3.0a4pre

The date-picker and time field are overlaid on this site making it difficult to select a date. In other browsers, the time field is right-aligned with the field above it (the FROM and TO fields).

Reproducible: Always

Steps to Reproduce:
1. Open http://www.sidestep.com/

Actual Results:  
Page elements are overlaid and crowded.

Expected Results:  
Proper spacing.

	Martijn Wargers (dead)
	Comment 3 • 17 years ago

This regressed when the reflow branch landed (between 2006-12-07 and 2006-12-08).

	Daniel Holbert [:dholbert] Assignee
	Comment 4 • 17 years ago

Here's a slightly reduced testcase.

- Expected behavior: Green region should fall within black border.  
 (outer div stretches horizontally to accommodate both blue + green div.)

- Buggy behavior: Green region sticks out of black border.
 (outer div doesn't stretch; it remains at 100px, the width of just green div.)

IE7, Safari 3.04, and FF2 all show Expected Behavior.  Current trunk shows Buggy Behavior.

	Daniel Holbert [:dholbert] Assignee
	Comment 5 • 17 years ago

Here's a reference for testcase 2.  (I've just added "float: left" to div.b)

FF3, FF2, Safari, and IE7 all agree on how to render "reference 2".

In IE7*, FF2, and Safari, "testcase 2" matches "reference 2"

*There's a small quirk in IE7 on "testcase 2" -- it shows a teeny bit of whitespace between the blue and green divs.  reference 2 doesn't have that whitespace.

	Daniel Holbert [:dholbert] Assignee
	Comment 8 • 17 years ago

This set of 4 testcases uses both left- and right-floated elements inside of divs and tables.

	Daniel Holbert [:dholbert] Assignee
	Comment 9 • 17 years ago

References for megatest.

Note: On IE7 and FF2, the final testcase and reference both expand to the width of the window, and as a result of this widening, they don't match each other.

However, in FF3/Trunk and in Safari 3, the final testcase and reference don't expand.  Assuming we keep that behavior, they should match* in Trunk, after this bug is fixed.  (They do currently match in Safari 3.)

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 10 • 17 years ago

The site looks good to me. This was probably affected by bug 134706, so I'm not sure which testcases are valid anymore.

Daniel, it would be a bit simpler to follow what's going on if there was just one testcase showing the actual bug, plus some prose explaining what the correct rendering would be (and why).

Anyway, marking nonblocking since the site is fixed.

	Daniel Holbert [:dholbert] Assignee
	Comment 11 • 17 years ago

(In reply to comment #10)
> This was probably affected by bug 134706, so I'm not
> sure which testcases are valid anymore.

testcase 2, testcase 3, and "megatest" are all still valid & broken.  I don't  remember offhand what the correct rendering is of martijn's original testcase, but I'm guessing that's still valid/broken as well.

> Daniel, it would be a bit simpler to follow what's going on if there was just
> one testcase showing the actual bug, plus some prose explaining what the
> correct rendering would be (and why).

Sorry if this bug page is a bit confusing.  Updating summary to indicate the issue here.

The correct rendering would be for each posted testcase to match its corresponding reference case.  The current trunk behavior is a regression from Firefox 2.

Essentially, a floated div followed by a normal div will result in both divs being on the same line, side-by-side. But when they're wrapped by *another* floated div, the wrapper shrinkwraps to the max of their widths, when it should shrinkwrap to the *sum* of their widths.

For example, in "testcase 2" (attachment 292683 [details]), trunk is currently shrinkwrapping the outer div's width to
     MAX(div_a.width, div_b.width)
but I think it should be shrinkwrapping its width to
     SUM(div_a.width, div_b.width)
which is what FF2 does.

Seeing as this is a layout regression, I'd suggest that this should still be a blocker, though probably with a low priority (maybe P3-P5) given that it doesn't currently affect any known sites.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 12 • 17 years ago

OK, this needs David's attention.

	David Baron :dbaron:
	Comment 13 • 17 years ago

This looks a lot like bug 414558.  I think we decided there that the new behavior (now that the overflow:hidden box drops down below the float rather than sticking out of its container) is better.

	Daniel Holbert [:dholbert] Assignee
	Comment 14 • 17 years ago

(In reply to comment #11)
> testcase 2, testcase 3, and "megatest" are all still valid & broken.

Sorry -- I just realized I was using a new definition of "broken" here.

In particular, I meant "broken" in the sense described later on in comment 11, but NOT in the sense of the "buggy behavior" described in Comment 4 -- that buggy behavior is now fixed. (probably by bug 134706)

	Daniel Holbert [:dholbert] Assignee
	Comment 15 • 17 years ago

Ok, I'm re-updating the summary to indicate the *original* buggy behavior, as it was described in comment 4.

Closing this bug as WORKSFORME, because:
 - the original buggy behavior is fixed (probably by bug 134706)
 - while our new behavior doesn't match the supposed "reference cases", we do match Opera, and dbaron said in comment 13 that our new behavior is preferred.

If it's decided at some point that we *should* match the reference cases, we can file a new bug on that.