Last Comment Bug 359135 - [reflow branch] Blocks with new block formatting context are to wide when adjacent to floats
: [reflow branch] Blocks with new block formatting context are to wide when adj...
Status: VERIFIED FIXED
[ComputeSize aAvailableWidth]
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-01 21:52 PST by philippe (part-time)
Modified: 2006-12-05 21:37 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case (1.20 KB, text/html)
2006-11-01 21:54 PST, philippe (part-time)
no flags Details
Screenshot of test case in WebKit (33.65 KB, image/png)
2006-11-02 16:32 PST, philippe (part-time)
no flags Details

Description philippe (part-time) 2006-11-01 21:52:33 PST
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) 2006-11-01 21:54:24 PST
Created attachment 244388 [details]
test case
Comment 2 Boris Zbarsky [:bz] (TPAC) 2006-11-02 09:16:44 PST
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-7 (busy September 14-25) 2006-11-02 09:30:27 PST
According to the spec, the latter.
Comment 4 Boris Zbarsky [:bz] (TPAC) 2006-11-02 10:57:31 PST
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-7 (busy September 14-25) 2006-11-02 13:04:49 PST
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) 2006-11-02 16:30:22 PST
(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) 2006-11-02 16:32:56 PST
Created attachment 244518 [details]
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 [:bz] (TPAC) 2006-11-03 07:27:08 PST
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-7 (busy September 14-25) 2006-12-05 13:20:46 PST
Fixed on reflow branch.

Note You need to log in before you can comment on or make changes to this bug.