My first guess at where this would be going wrong is that for some reason this test would be failing when it should be passing and allowing us to place the float immediately.

... in particular, it seems that ComputeFloatISize is returning NS_UNCONSTRAINEDSIZE.

... which isn't at all surprising given how it works.

It seems like we really could just reflow the float before deciding whether it fits, as long as we know not to reflow it again later (or as long as we know the second reflow will be efficient -- which it should be in most cases, although unfortunately not all). It might be worth restructuring the code to reflow the float earlier and then worry about placement -- and perhaps restructure the interaction between BlockReflowInput::AddFloat and BlockReflowInput::FlowAndPlaceFloat (and maybe even also nsBlockFrame::ReflowFloat, although that may not be needed here).

In FlowAndPlaceFloat(), condense two identical assertions about float frame
parent into one.

FlowAndPlaceFloat() calls ReflowFloat() only once, either an early reflow (when
earlyFloatReflow is true) or a late reflow (when earlyFloatReflow is
false), so the reflow status is always fresh.

These are small printf statements that are not build by CI, which increase
maintenance burden.

Depends on D151203

Both the method's documentation and implementation already use logical
coordinate.

Depends on D151204

This is a preparation for the next part.

Depends on D151205

First of all, nsBlockFrame::AdjustFloatAvailableSpace() is misleading. It
doesn't adjust the argument aFloatAvailableSpace at all, nor does it use any
fields in nsBlockFrame. It simply returns the available space in the parent
block's content area. Thus, I move it into BlockReflowState, and have it return
the available size rather than a rect because a size is sufficient for reflowing
a float.

Also, nsBlockFrame::ReflowFloat() only cares about the available size, but not
the position of the available space, so it is sufficient to pass a LogicalSize
computed by the new method ComputeAvailableSizeForFloat().

In FlowAndPlaceFloat(), there is a loop searching for a wide enough band to
place the float. We don't need to adjust availSize every time mBCoord is changed
in the loop. We can just call ComputeAvailableSizeForFloat() to get a new
available size before reflowing the float in the !earlyFloatReflow branch.

This patch shouldn't change the behavior.

Depends on D151206

This patch is a preparation for the next part, and doesn't change the behavior
yet.

FlowAndPlaceFloat() is used to return true and false. This patch changes its
return value true to PlaceFloatResult::Placed and false to
PlaceFloatResult::ShouldPlaceInNextContinuation.

In the next part, we'll move the logic dealing with "below the current line
floats" into FlowAndPlaceFloat(), and make it return
PlaceFloatResult::ShouldPlaceBelowCurrentLine.

Depends on D151207

The old code in AddFloat() used to call nsBlockFrame::ComputeFloatISize() to
compute a float's inline-size, compare it with current line's available
inline-size, and determine whether FlowAndPlaceFloat() should be called.
However, it doesn't handle an orthogonal float with an auto block-size.

Luckily, FlowAndPlaceFloat() already has logic dealing with orthogonal
floats (bug 1141867), so this patch defers the decision to place a float below
the current line until the float's margin inline-size is computed in
FlowAndPlaceFloat().

Depends on D151208

https://hg.mozilla.org/mozilla-central/rev/48331f7fdc7d
https://hg.mozilla.org/mozilla-central/rev/6953d70bc28e
https://hg.mozilla.org/mozilla-central/rev/aebe719d769b
https://hg.mozilla.org/mozilla-central/rev/d6a37445d86b
https://hg.mozilla.org/mozilla-central/rev/e53ad6f93a0f
https://hg.mozilla.org/mozilla-central/rev/a70aa231b13e
https://hg.mozilla.org/mozilla-central/rev/d08bab0259f7