When nsBlockReflowState::AddFloat tries to place a float on the current line, it calls FlowAndPlaceFloat, which figures out where to put the float given the positions of already-placed floats. When FlowAndPlaceFloat can't fit the float on the current line (in my testcase, because the current line is impacted by a float), it moves to the next "band", and tries to place the float there. However, it fails to take into account the possibility that the current line's line-box may overlap the next band, so in the testcase it places the float there but then we go back and finish reflowing the line and it does indeed end up overlapping the float. In the testcase, Safari 3.1 has the same behaviour as Gecko trunk. Opera 9.5beta moves the H to the next line --- that doesn't seem right to me either, although mabye it is.

I mean, Opera moves the H to the start of the line below the green float.

I considered the rendering that leaves the H where it is and moves the right float down below the H. But actually I think Opera's rendering is more correct than that, given "# A floating box must be placed as high as possible." in http://www.w3.org/TR/CSS21/visuren.html#float-position

This testcase shows bug 25888; I'm not sure what the bug you're describing is, though.

(I also think the testcase might be a little more interesting with the H before the float. That case seems a little more relevant to bug 50630. (This bug came from bug 50630 comment 43.)

The bug I'm talking about is bug 25888.

Though this wasn't fixed by the fix for bug 25888, which only fixed cases where the float came from prior to the line. Current Chrome renders the testcase correctly, though.

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)