Closed Bug 427782 Opened 12 years ago Closed 12 years ago

Wrong position of div with width and overflow


(Core :: Layout: Block and Inline, defect)

Not set





(Reporter: jan.halasa, Assigned: dbaron)



(Keywords: regression, testcase)


(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

in HTML that I will attach, there are 3 top-level divs. They are rendered differently in Firefox 3.0b5 then in other browsers (FF 2.0, MSIE 7, Opera 9.26, Safari 3.1).

Reproducible: Always

Steps to Reproduce:
1. open attached HTML test case

Actual Results:  
If your window is narrower than 900px, div with id="blockWithScrollbars" (green one) is placed under one with id="leftBlock" (yellow). 
Layout is good:
- if the window is wider
- if I remove "headerBlock" div
- if I add <div style="clean: both" /> after "headerBlock" div

Expected Results:  
Div with id="blockWithScrollbars" should stay on the right hand side by the "leftBlock" and it should get horisontal scrollbar if the window is narrower then width of both blocks.
Attached file HTML test case
Component: General → Layout: Block and Inline
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Hardware: PC → All
Version: unspecified → Trunk
Seems to work fine here with a trunk build on WinXP. Can you try a current trunk build from and take a look if you still experience this bug with that build?
From Gecko/2008040907 Minefield/3.0pre
From Firefox
Hello Frank, I tried the latest build, but the result is the same. I attached screenshots, one from the latest build which shows wrong layout and one from Firefox 2 which is good.
The block with overflow:auto and auto width should not drop below the floated block.

Gecko/2008012804 Minefield/3.0b3pre
Gecko/2008012904 Minefield/3.0b3pre

--> bug 134706
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression, testcase
Blocks: 134706
We have a bug on this already (the MSDN thing, iirc), and it's in Tech Evangelism...  That is, the current behavior seems to be the one that was decided to make the most sense.
Whiteboard: DUPEME
(In reply to comment #7)
> We have a bug on this already (the MSDN thing, iirc), and it's in Tech
> Evangelism...  That is, the current behavior seems to be the one that was
> decided to make the most sense.

Are you referring to bug 421758 ?

In this case, we have a fixed-width block inside a block (green) with overflow:auto. I really don't see why the green block should drop below the float, instead of showing scrollbars as Safari and Opera do (and Gecko 1.8).
> Are you referring to bug 421758 ?


> I really don't see why

Because the preferred width of the scrollframe is 700px, so we clear it past floats if that doesn't fit.  The history of that is all in bug 421758, if I recall correctly.
So I was thinking about this...  Is there a reason that we're using the intrinsic min-width instead of computing the size given the available space?

It really does seem to me like this testcase should work the way philippe expects it to and the way all other UAs render it...
That is, for the particular case of block-level scrollframes we have the weird situation where their auto width can easily be smaller than their intrinsic min-width.  We have that for percentage widths too, and OneWidthToClearPastFloats handles that by computing the width in that case.  It would really make the most sense to me to take the path it takes for percentage widths for all cases...
I guess to do that we'd need to somehow factor the floats into the available width...  Note that per CSS spec the computed width of that overflow:auto block should be the entire width of the body, but there is the weasel-wording that UAs can reduce that when next to a float as they see fit.  In other words, pretty much anything we choose to do here is correct per spec.
It sounds like you're effectively arguing that the intrinsic minimum width of scrollframes should be 0; I sympathize somewhat, but that's a little risky to change at that point (we changed it to fix a Zimbra bug, IIRC).
I guess the question is whether fixing the Zimbra bug is causing us to break other sites...  That's what it's looking like to me, to be honest.

Between breaking Zimbra and breaking MSDN, which is worse?

But really, I'm not arguing that the intrinsic min width should be 0.  I'm arguing that we might want to not use the intrinsic sizing mechanism to determine the "width to clear"...

(As an aside, there's one other inconsistency in this code: in the percentage width case we don't include margins in the width to clear, but in all other cases we do.)
Yeah, I just noticed that while fixing bug 427129.

That said, I think you're right about this case -- we probably should just do the %-case handling all the time, and I don't think it's inconsistent.

Is this case the same one that's breaking MSDN, or is that another use of min-width?
This case is the same one that's breaking MSDN, as far as I can tell.

If we just do the percentage-case handling for auto width blocks, they'll use the parent block width.  So we'd clear the scrollframe past the float no matter what its intrinsic min-width is.
Right, but we can use the available width as the available width, rather than the containing block width.  The available size should always be ignored in the %-width case, but it matters for the auto width case.  I just need to think about how that interacts with ignoring margins.
If we know what the available width here, I think it would make the most sense to do the reflow state thing and then return the ComputedWidth() + ComputedBorderPadding + ComputedMargin...

Unless we want to fix the margin thing that got changed in CSS2.1, which we probably don't.
It sounds like we want to fix this for 1.9 and we know how, so lets do it.
Flags: blocking1.9? → blocking1.9+
Assignee: nobody → dbaron
Whiteboard: DUPEME
Fixed by checkin of bug 427129 to trunk, 2008-04-14 18:06 -0700.
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Duplicate of this bug: 422883
Duplicate of this bug: 429567
verified with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041704 Minefield/3.0pre
You need to log in before you can comment on or make changes to this bug.