Closed Bug 1739260 Opened 2 years ago Closed 1 year ago

hang with floats and aspect-ratio


(Core :: Layout: Floats, defect)




102 Branch
Tracking Status
firefox102 --- fixed


(Reporter: dholbert, Assigned: boris)


(Blocks 1 open bug)


(Keywords: hang)


(2 files)


  1. Load attached testcase.

The content process hangs indefinitely (or at least for > 30 seconds, which is as long as I waited).

No such hang.

Credit to iank from the Chrome team for sending me this testcase.

Here's a profile (again, just for ~30 seconds of the hang):

Component: Layout → Layout: Floats

A pernosco session of this issue (with me ultimately killing Firefox via Ctrl+C) is available at

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(boris.chiou)
Assignee: nobody → boris.chiou
Severity: -- → S3
Flags: needinfo?(boris.chiou)
Severity: S3 → S2

My initial investigation for this bug:
nsIFrame::ComputeSize() (called when we construct childReflowInput) return (0, 0) for the element with aspect-ratio when doing reflow [1]. When we try to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in nsIFrame::ComputeSize(), and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [2] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.


Dropping to S3 since we don't know of any actual web content affected by this, at this point (though it would be nice to fix!)

Severity: S2 → S3
Blocks: aspect-ratio

This test case hangs because:

  1. We get a flow area which is occupied by an element with float:right,
    so |AvailableSpaceShrunk()| doesn't work as we expected, and we hit an
    assertion in this function.
  2. The size of |floatAvoidingBlock| keeps changing with different containing
    blocks (note: because of aspect-ratio and auto sizes), so we never hit the
    break condition if the new and old float available spaces are the same.
  3. The above two reasons make |FloatAvoidingBlockFitsInAvailSpace()| always
    return true, because a 0x0 FloatAvoidingBlock always fits in any space.
    so we always stay in the same band (i.e. same |aBCoord|), and never go to
    the next band.

A possible way is to make sure we get a suitable available area for
|floatAvoidingBlock|, so the logic of positioning |floatAvoidingBlock|
works as we expected.

Pushed by
Force to advance next band if we cannot get a suitable float available space. r=dholbert
Created web-platform-tests PR for changes under testing/web-platform/tests
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.