Closed Bug 1739260 Opened 9 months ago Closed 3 months ago

hang with floats and aspect-ratio

Categories

(Core :: Layout: Floats, defect)

defect

Tracking

()

RESOLVED FIXED
102 Branch
Tracking Status
firefox102 --- fixed

People

(Reporter: dholbert, Assigned: boris)

References

(Blocks 1 open bug)

Details

(Keywords: hang)

Attachments

(2 files)

STR:

  1. Load attached testcase.

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

EXPECTED RESULTS:
No such hang.

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

Here's a profile (again, just for ~30 seconds of the hang): https://share.firefox.dev/3q4BVf3

Component: Layout → Layout: Floats

A pernosco session of this issue (with me ultimately killing Firefox via Ctrl+C) is available at https://pernos.co/debug/5Mxl-UA3ee3zTo2IWBJpzw/index.html

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
Status: NEW → ASSIGNED

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.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3842-3844
[2] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978

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 bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fb1114750895
Force to advance next band if we cannot get a suitable float available space. r=dholbert
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34131 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
Upstream PR merged by moz-wptsync-bot
Duplicate of this bug: 1763431
You need to log in before you can comment on or make changes to this bug.