What steps will reproduce the problem?
1. Open https://output.jsbin.com/hebedit/quiet (also copied in attachment)
2. Observe rendering.
3. Resize the window.

What is the expected result?
Green square in step 2.  Rendering does not change on resize in step 3.

What happens instead of that?
Square is half red in step 2.  Resizing the window makes the whole square green.

Additional information:
The interaction of floats and negative margins is subtle, but Firefox and IE agree the square should be fully-green.  Certainly the rendering should not change on resize.

In Blink and WebKit, the first layout pass (once the content is in the DOM) assigns offsetLeft == 0 to the .content div, leading to the half-red state.  The second layout pass (if and when it occurs) assigns offsetLeft == 50 to the .content div, leading to the fully-green state.

The offsetLeft value is computed in LayoutBlockFlow::DetermineLogicalLeftPositionForChild (where "this" == .container div).  This method sees ContainsFloats() == false during the first layout pass, and ContainsFloats() == true during the second layout pass, for reasons not understood.

This test case is based on the layout test fast/block/float/avoid-floats-when-negative-margin-top-5.html, with a modification to disable scrollbars.  The layout test passes because the removal of the frame's initial vertical scrollbar triggers a second layout pass.

This bug was discovered while investigating test failures on patchset 1 of http://crrev.com/c/838249/1.  That patchset caused the initial vertical scrollbar to be removed before the content was in the DOM.  (This isn't desirable, but it shouldn't have broken layout.)

There were many other layout tests that failed with this patchset, that I didn't investigate.  So, it's possible there is a whole class of bugs where we rely on a second layout pass to correct the mistakes of the first.
 

Deleted: floats.html 460 bytes

floats.html 460 bytes View Download