359135 - [reflow branch] Blocks with new block formatting context are to wide when adjacent to floats

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[philippe (part-time)]

Blocks that establish a new block formatting context (overflow:hidden, table) are to wide when preceded by a floated block. The width is incorrectly computed to the width of the parent block.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061102 Minefield/3.0a1

Comment 1

[philippe (part-time)]

Attachment: test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yeah....  We should probably either change the computed width of those blocks/tables based on what floats are currently on the line or change the block-placement code to just clear them past the floats...

Comment 3

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

According to the spec, the latter.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So basically in nsBlockFrame::ReflowBlockFrame once we construct the child's reflow state if the mComputedWidth + mComputedBorderPadding + mComputedMargin is bigger than the availSpace.width we should try clearing past floats?  At least in cases wheh the child block is a block formatting context?

Comment 5

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

We might need to be careful with auto margins, though.  But basically, yes, since CSS2.1 says (in 9.5):

The margin box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. 

Comment 6

[philippe (part-time)]

(In reply to comment #3)
> According to the spec, the latter.
> 
The blocks in the testcase have an auto width. Behaviour in current trunk builds, Gecko 1.8.1, and all other browsers (Safari, Webkit nightly builds, Opera, IE Mac, IE 6 and 7 Windows, Konqueror 3.5.4, iCab 3.0) is to account for the width of the floated block when computing the width of the block that establish a new block formatting context. This is also how I understand 9.4.1 in CSS 2.1.
(Most browsers, except Gecko and iCab, handle the margins incorrectly, but that is not the point of this bug).

Does that mean that this behaviour is wrong ?

If those blocks have a declared width, and there is not enough space next to the float, then yes, they should drop below (clear) the floated block. Gecko (non reflow) has some bugs on this, like bug 350474).

Comment 7

[philippe (part-time)]

Attachment: Screenshot of test case in WebKit

This is how current WebKit build handles the test case. Not the incorrect horizontal margin handling between the 2 blocks. The computed width of the element next to the float is correct, however.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So... I dunno about the table case, but CSS2.1 section 10.3.3 applies to the overflow:hidden case.  Per that part of the spec, the block's width should not depend on whether it's overflow property is set to hidden or not.  It's not clear how 9.4.1 is supposed to interact with this.

I'll raise it with the CSS WG, I guess.

Comment 9

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

Fixed on reflow branch.