427782 - Wrong position of div with width and overflow

Status: VERIFIED FIXED

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

Description

[Jan Halasa]

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

Hello,
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.

Comment 1

[Jan Halasa]

Attachment: HTML test case

Comment 2

[Frank Wein [:mcsmurf]]

Seems to work fine here with a trunk build on WinXP. Can you try a current trunk build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and take a look if you still experience this bug with that build?

Comment 3

[Jan Halasa]

Attachment: Screenshot of wrong rendering.

From Gecko/2008040907 Minefield/3.0pre

Comment 4

[Jan Halasa]

Attachment: Screenshot of good rendering.

From Firefox 2.0.0.12

Comment 5

[Jan Halasa]

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.

Comment 6

[philippe (part-time)]

The block with overflow:auto and auto width should not drop below the floated block.

Works
Gecko/2008012804 Minefield/3.0b3pre
Fails
Gecko/2008012904 Minefield/3.0b3pre

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-27+04%3A00%3A00&maxdate=2008-01-29+04%3A00%3A00&cvsroot=%2Fcvsroot

--> bug 134706

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[philippe (part-time)]

(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).

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Are you referring to bug 421758 ?

Yes.

> 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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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...

Comment 11

[Boris Zbarsky [:bzbarsky]]

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...

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

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

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).

Comment 14

[Boris Zbarsky [:bzbarsky]]

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.)

Comment 15

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

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?

Comment 16

[Boris Zbarsky [:bzbarsky]]

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.

Comment 17

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

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.

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

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

It sounds like we want to fix this for 1.9 and we know how, so lets do it.

Comment 20

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

Patch in bug 427129.

Comment 21

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

Fixed by checkin of bug 427129 to trunk, 2008-04-14 18:06 -0700.

Comment 24

[philippe (part-time)]

verified with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041704 Minefield/3.0pre